Tag Archives: server

how to setup a cronjob in cPanel

A cronjob (short for c(h)ron(ological) job) is like getting the server to automatically perform an action (eg run a php script) on a schedule you specify. It’s straightforward setting up a cronjob using cPanel, all except one step: the command to get the action performed. This article is about setting up a cronjob on a Linux server (part of a LAMP installation) to run a php script.

Step 1: Find out where php is being run from on your server (LAMP server)
This first step is useful for later on and the bit that people new to setting up cronjobs may not be aware of. To enter a command in a cronjob you need to tell the cron handler where php is.

Create where.php and upload to your store’s root directory (eg /public_html):

Then call the script from a browser, eg: www.mysite.com/where.php
Copy the path shown for use in step 5.

(If this doesn’t work, try using usr/bin/php or usr/local/bin/php. If neither of these work, contact your hosting company or tech.)

Step 2: Access cPanel and click the cronjob link:

link to cronjob in cpanel

Step 3: Enter a contact email address
This is so that you can get error messages or completion notifications when the cronjob has run. (However see Step 5 below for a reason why you won’t get any emails.)

email address for cronjob notifications

Step 4: schedule the cronjob
A dropdown of preset timings should be enough for most people. Point and click. I use the ‘every minute’ schedule to test the cronjob, then change this later to however often it’s needed.

scheduling your cronjob

Step 5: THE IMPORTANT ONE – adding in the command
You can break down the command into 3 parts (the [ ] are just there to separate the parts out, but notice the spaces after each part – you need these in the command you write):

[PATH TO PHP] [EXTRA ARGUMENTS] [PATH TO PHP SCRIPT]

This is an example command:

command breakdown used in cronjob

[PATH TO PHP] – you found in Step 1 – here it is /usr/bin/php – this isn’t always the case. Add this at the start of the command. Leave a space after it.
[EXTRA ARGUMENTS] – these are optional, you can use more than one at a time and there are several others. Here I’ve used only -q which is a way of suppressing headers. Leave a space after any arguments.
[PATH TO PHP SCRIPT] – this is the complete path to your php file on your server (not just from the store’s root, the server’s root.)

Added extra (optional)
There is a final piece of code you can add after the [PATH TO PHP SCRIPT]:
>/dev/null 2>&1

Basically this dumps any output from the php script to a ‘blackhole’, so no ‘output’ will be shown on the screen. If you add this to your command it will also stop any email notifications from being sent – as all output is gone, right?

So the image below takes you from Step 4 Scheduling through to now, where you add the command and save the cronjob.

schedule, add in command, add cronjob

The final step is to add the cronjob, which will then result in this success screen:

cronjob added through cPanel

stop google from indexing https secure pages of your website

To stop google and other bots from indexing your website https pages you need to create a new version of a robots file and add a conditional to your store’s root htaccess file. Note – your server should be running the Apache mod_rewrite module for this to work.

robots_ssl.txt
Simply create and upload a txt file containing the following code to your store’s root directory:

User-agent: Googlebot 
Disallow: / 

User-agent: * 
Disallow: /

modify the store’s htaccess file
Add the following lines near the top of your htaccess file:

RewriteCond %{SERVER_PORT} ^443$ 
RewriteRule ^robots.txt$ robots_ssl.txt

Check your Google Webmaster account to check this is working correctly.

top 10 ways to secure your oscommerce-based store, security

Here is a list of basic security measures you can carry out to protect your store. Use it as a checklist and consider implementing any missing from your server’s security policy. Some of security steps have certain server requirements that may or may not be available to you, depending on your hosting plan. This post is for stores on Linux servers with LAMP (LinuxApacheMysqlPhp) configurations.

These ideas come from a variety of sources, in particular zen-cart which includes a number of useful security features and recommendations in its cart.

  • Check and Set Permissions
    Permissions are assigned to each folder and file which indicate access rights to specific users or groups.
  • Folders should be a maximum of 755, however certain folders – /images; /admin/backups; /tmp; may require 757 for writing to, depending on your server configuration. All files should be 644 (configure.php files 444 if possible)
  • Disable the ‘Allow Guest to Tell a Friend’ feature
    Some carts allow visitors to the site to send emails through this feature. By disabling this feature, you will prevent non-logged-in customers from using your server to send ‘spam’ email messages.
  • Update your store and module software to the latest versions and patches
    With every new software release, there are usually security or bug fixes which improve the functionality and stability of your store. If you don⬔t upgrade, hackers will be able to easily exploit your websites from known vulnerabilities.
  • Use local htaccess files to restrict script execution, access
    For local htaccess files to work, the server must be setup to allow this, usually in with the command ‘AllowOverride All’ or ‘AllowOverride Limit’ in the apache/conf/httpd.conf file. Check with your hosting company if this is configured.
  • In the htaccess file itself, start by denying access to everything:

  Order Deny,Allow
  Deny from all
  • Then allow access to only certain files:
  • 
      Order Allow,Deny
      Allow from all
    
  • For example, the /images folder:
  • 
      Order Allow,Deny
      Allow from all
    
  • Prevent these variables from being used in say the /cache folder:
  • 
      Order Deny,Allow
      Deny from All
    
    
  • If a folder of downloads, the code can be added so the file is treated automatically as ‘Save As’ and not run as an application:
  • 
      Order Allow, Deny
      Allow from all
      ForceType application/octet-stream
      Header set Content-Disposition attachment
    
  • If you want to prevent snoopers from listing the contents of a folder, there are several ways to do this. The first thing to establish is whether your hosting company already does this via the Apache config file. Ask your hosting company if the following exist in the Apache config file:
    DirectoryIndex index.php
    Options -Indexes -ExecCGI
    (the -ExecCGI is particularly useful as it prevents hackers executing scripts in the folder)
  • If not, ask what the DirectoryIndex is set to (usually it will be “index.php”) – if this is the case, you can add this to a local htaccess file :
    IndexIgnore */*

    or you can create a blank index.php and upload that to the folder

  • Monitor your error and access logs
    You’re looking for suspicious entries here – any links that go to pages not on your site; links that have http after the index.php; that sort of thing. Your store my have /error or /debug folders in its directory structure – check here too.
  • Backup your store regularly
    mySQL database – this can be done through Admin/Tools/Mysql Backup. Use whatever compression is available. Avoid downloading the compressed backup over an unsecured (http://) connection. The zipped backup file is created in admin/backups, so consider how to secure this folder too.
  • Your store’s files – these AREN’T saved using the mySQL backup and must be done separately. Basically you need a copy of everything in /catalog (or ‘root’ which may be called ‘public_html’.)
  • Server settings – more applicable to stores running on their own server (in which case you should have a maintenance program set up already), however check with your hosting company to see how they manage backing up the server configurations.
  • Check with hosting company on what they have done to make your site secure
    Your store can be severely compromised if your hosting company hasn’t correctly secured the server. There are many configuration features that can be enabled by them (eg suHosin, apache config settings and php.ini settings are a few) – so it pays to be clear on what they’re doing to make your store more secure. This is particularly important if you’re running on a shared server and using shared SSL (not recommended.)
  • Get a dedicated SSL certificate and static IP address for your store
    This will help in many ways and if you’re serious about presenting a dependable, secure store, these are essential requirements.
  • Seek help
    If your business warrants, or you still want additional assurance (esp if running forum software on your site, or other scripts outside of your e-cart software), hire a security consultant to check your site regularly and give you peace of mind in exchange for a few dollars.
  • Admin-specific security
    Check this post about securing your admin with specific points related to this important utility’s function. The admin is often the point of entry for hacking attempts.
  • speed up your site – set expiration in cache control

    Another useful Apache utility called mod_headers can be used to set an expiration date in the future of files like images and static html pages. This means that rather than loading image files or unchanging html code every time you visit a site, a check will be made in the cache of your browser to see if there is already an existing copy of the file requested. If the file is still ‘fresh’ – ie within the period specified by the expiration, the cached version of the file will be used and no ‘refresh’ call will be made to the host server.

    Your server needs to have mod_headers enabled before being able to use these directives. You can add this code to your root htaccess file, or http.conf / vhosts.conf if you have access to those.

    
    #cache html and htm files for one day   
       
    Header set Cache-Control "max-age=43200"  
       
      
    #cache css, javascript and text files for one week   
       
    Header set Cache-Control "max-age=604800"  
       
      
    #cache flash and images for one month   
       
    Header set Cache-Control "max-age=2592000"  
       
      
    #disable cache for script files   
       
    Header unset Cache-Control   
    
    

    When changing conf files on an Apache server, remember to Apply Changes and restart the Apache server for the directives to take effect.

    Another approach is to use ExpiresByType commands in the htaccess file:

    # turn on the module for this directory
        ExpiresActive on
    # set default
        ExpiresDefault "access plus 24 hours"
        ExpiresByType image/jpg "access plus 1 months"
        ExpiresByType image/gif "access plus 1 months"
        ExpiresByType image/jpeg "access plus 1 months"
        ExpiresByType image/png "access plus 1 months"
        ExpiresByType image/x-icon "access plus 1 months"
        ExpiresByType text/css "access plus 1 months"
        ExpiresByType text/javascript "access plus 1 months"
        ExpiresByType application/javascript "access plus 1 months"
        ExpiresByType application/x-shockwave-flash "access plus 1 months"

    Final tip: set eTags to null using:

    Header unset ETag
    FileETag None

    speed up your site – use compression

    If your server is running Apache 2.xx then mod_deflate can be used to compress certain file types, which will give a real boost in loading speed as the client’s browser will be uncompressing the content, rather than the server carrying the full load.

    To enable mod_deflate, add the following to root htaccess (or ideally http.conf or if on a virtual server, vhosts.conf)

    
    
    SetOutputFilter DEFLATE
    
    

    This snippet of code compresses javascript and css for unpacking by the visitor’s browser.

    If your server is running Apache 1.x then mod_gzip can be used. This can be added to the root htaccess file.

       
        mod_gzip_on         Yes   
        mod_gzip_dechunk    Yes   
        mod_gzip_item_include file          .(html?|txt|css|js|php|pl)$   
        mod_gzip_item_include handler       ^cgi-script$   
        mod_gzip_item_include mime      ^text.*   
        mod_gzip_item_include mime      ^application/x-javascript.*   
        mod_gzip_item_exclude mime      ^image.*   
        mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*   
     
    

    You might also like to enable Gzip Compression through Admin/Configuration/Gzip Compression, set at 9.