If you are pulling your hair out trying to figure out why you are seeing a 501 error in your Google Checkout integration console I may well have the answer and solution for you.
This is the error message you will see in the integration console.
We encountered an error trying to access your server at https://domain.co.uk/googlecheckout/api/ -- the error we got is Sending failed with HTTP response code: 501. Response body was: <HTML> <HEAD> <TITLE>501 Not Implemented</TITLE> </HEAD> <BODY> <H1>Not Implemented</H1> The page you are looking for cannot be displayed because a header value in the request does not match certain configuration settings on the Web server.<P> <HR> <ADDRESS> Web Server at domain.co.uk </ADDRESS> </BODY> </HTML> <!-- - Unfortunately, Microsoft has added a clever new - "feature" to Internet Explorer. If the text of - an error's message is "too small", specifically - less than 512 bytes, Internet Explorer returns - its own error message. You can turn that off, - but it's pretty tricky to find switch called - "smart error messages". That means, of course, - that short error messages are censored by default. - IIS always returns error messages that are long - enough to make Internet Explorer happy. The - workaround is pretty simple: pad the error - message with a big comment like this to push it - over the five hundred and twelve bytes minimum. - Of course, that's exactly what you're reading - right now. -->
The first thing to do is log into your server via SSH and examine the error logs.
find the error logs, open the file up in vi using this command:
vi error_log
Then go to the bottom of the file using the [shift] + [g] shortcut. Then to search backwards in the log use the following command:
?ModSecurity
If you find something with this error message then you have mod security installed. If you search around you may well find an error message like this:
[Thu Mar 26 10:22:11 2009] [error] [client 94.229.166.12] ModSecurity: Access denied with code 501 (phase 2). Match of “rx (?:^(?:application\\/x-www-form-urlencoded(?:;(?:\\s?charset\\s?=\\s?[\\w\\d\\-]{1,18})?)??$|multipart/form-data;)|text/xml)” against “REQUEST_HEADERS:Content-Type” required. [file "/etc/httpd/modsecurity.d/modsecurity_crs_30_http_policy.conf"] [line "71"] [id "960010"] [msg "Request content type is not allowed by policy"] [severity "WARNING"] [tag "POLICY/ENCODING_NOT_ALLOWED"] [hostname "247electrical.co.uk"] [uri "/googlecheckout/api"] [unique_id "-UMIen8AAAEAAFsDLH4AAAAB"]
This error message tells us which particular rule is causing it to fail. What we need to do now is either edit this rule or disable it altogether. I will first try to edit it so that the request can get through, but the rule is still active. The rule we need to edit is in this rules file:
modsecurity_crs_30_http_policy.conf
and is on line 71.
I’m no mod security expert. Having had a quick look through the documentation I am not sure how to edit this rule to allow Google Checkout callbacks through. So for the time being I am going to disable this particular rule altogether by adding a # in front of lines 70,71 and 72.
If any mod security experts out there read this blog and know a better solution please do post it in the comments.
More…
Amazon helpfully supply a java package called AMTU which does the grunt work of the XML integration for Amazon marketplace. With AMTU you can easily update products, stock levels, prices and also grab order info etc.
Being based on Java, AMTU can run on pretty much any operating system. It uses a “hot folder” system so integration with client systems is as simple as dropping files into certain folders.
There are some good instructions for setting up AMTU on windows. That’s great if you want to run it on your desktop (or a windows server if you are that way inclinded…. 
). However if you are one of my clients you are running a Linux server and need it setting up on there.
Unfortunately the documentation for AMTU on Linux is pretty lightweight. This blog post aims to help out anyone struggling with getting AMTU working on their server.
Before you start. Open up the README file (just download the package to your local machine). Have a quick read through and then understand that the README is simply wrong. It is a guide at best, but not strict instructions. They definitely haven’t made it easy for us.
Speaking to Amazon about this, it is apparent that AMTU was developed by someone who is no longer around to support it. They have released it as open source software and basically left us to it. They are not willing to support it themselves.
Here’s my instructions:
1. Log into SSH as root on your server.
Using your favourite SSH client. If you use linux you can just use the terminal, definitely my favourite way of handling SSH.
2. Navigate to the root folder that you want to install AMTU to.
cd /opt
3. Download the AMTU Files
mkdir amtu
cd amtu
wget http://freefr.dl.sourceforge.net/sourceforge/amtu/amtu-linux-1.0.9.tar.gz
4. Unpack the Archive
tar -xvf amtu-linux-1.0.9.tar.gz
5. Edit the config files
5.1 Find your JAVA_HOME
This may change depending on what version of Linux you are using. If you are not sure then use the following command to find out:
cat /etc/issue
The following command will show you which Java version you are running. If you are it doesn’t work then it looks like you don’t have Java installed. Please see Apendix A for Java install instructions.
java -version
You need to find out the exact path for java. You can use this command:
find / -name java
This will display a few lines. There is usually only one Java folder though with the others being symlinks (shortcuts kind of ) to the Java folder.
5.2 Edit the Install.sh File
First get into the AMTU folder:
cd /opt/amtu/
Now make sure you have your path to the JRE noted down somewhere and open up the install.sh for editing. For me the path is /usr/bin/java
vi install.sh
(vi is a text editor for linux. If you are not familiar with it simply search for “vi common commands or something like that).
Now go to the top of the file and add a new line. Replace /usr/bin/java with your own path to Java.
export JAVA_HOME=/usr/bin/java
6. Run the Install Script
First we need to make the install script executable.
chmod a+x install.sh
Now run the install script.
./install.sh
7. Configure AMTU
This is where it gets interesting. AMTU is installed, but you haven’t given it any kind of information regarding your Amazon account so how will it be able to connect to your specific account??
You need to use the configure.sh script to do this. For me this wouldn’t work until I edited it and ran it manually. There is a configure.sh in the root amtu folder, however all this seems to do is run the configure script in the service folder.
Lets go straight to the service folder and get that one working.
cd /opt/amtu/service/bin
vi configure.sh
In this file they are mixing up the JAVA_HOME variable and appending /bin/java to it. I’m not really sure why they would do this.
First of all try running the script
./configure.sh
If you get an error like:
./configure.sh: line 3: /bin/java: No such file or directory
Then you will need to edit the file. For me to get it to work I had to remove the following:
$JAVA_HOME/bin/java
and simply replace it with my path to Java which is:
/usr/bin/java
Then run the script again and it will ask you a bunch of questions. For most questions the default answers seem fine to me. You will need to know your SMTP details. You will want to log into your seller central account as well so that you can copy relevant details from there.
If it is all successful you should get a message similar to the following:
Please standby while your account details are verified…
Ping was successful
Updating configuration… done!
To alter this configuration, please use the Configuration Utility in the directory you installed this application.
Exiting Application
8. Starting the AMTU and Monitor services
To start the amt and amt_monitor services you need to manually start them. You can also check the status of these processes.
First get into the bin folder
cd /opt/amtu/service/bin
check status
./amt status
./amt_monitor status
If they are not started simply run the start commands
./amt start
./amt_monitor start
Running these two commands should have created some folders in your DocumentTransport folder. To check this out simply go to the folder and check
cd /opt/amtu/DocumentTransport
ls
You should see a folder called logs and a folder called production. The production folder contains our Hot Folder for sending files up to Amazon.
7. Set up symlinks
Once everything is working nicely, you will probably want to create symlinks from folders accessible by PHP.
Navigate to the place that PHP can access and which you would like to place a symlink to the production/outgoing folder. Then use the following command – replace the details as necessary
cd /home/path/to/php/accessible
ln -s /opt/amtu/DocumentTransport/production/outgoing my_amtu_symlink_folder_name
8. Test it Out
All you need to do to test it out is to drop a file into the /opt/amtu/DocumentTransport/production/outgoing folder (or the symlink to this folder that you have just created). Then wait 5 minutes (cup of tea time) and come back. Now browse through the production folders. If the file is in the /sent folder then your upload has worked OK. If it is in the /failed folder then something has gone wrong.
If like me it didn’t work (surprise surprise) then you need to examine the log files to find out what the problem is. The best log to look in to start with is the audit_log.
cd /opt/amtu/DocumentTransport/logs
vi amtu_audit.log
To go to the bottom of the file use the vi shortcut [shift]+[g]
As for figuring out exactly why AMTU doesn’t like your feed file, I leave that bit to you.
Appendix
A. Install Java
These are instructions for a CentOS Linux install. Your Linux might be a different flavour. Simply search around for instructions for your specific setup.
A.1 Download JRE
Go to the Java downloads page
Find the link to the Linux Java JRE bin. (For CentOS you need the rpm version). Copy the link to your clipboard
cd opt
wget {link from clipboard for JRE download}
This will download the file. However as it is accessed via a script, it will give it a crazy long filename. Lets just rename that first. To rename a file with special characters simply wrap the filename in “” otherwise it won’t work.
ls
now copy the filename to your clipboard
now paste it into this command
mv "filename from clipboard" jre-rpm.bin
Now we need to set the file as executable
chmod a+x jre-rpm.bin
Now we install it
./jre-rpm.bin
This will then flash up a bunch of terms and conditions. Just hold down [return] until you get to the bottom, then type “yes”.
To check its all installed use the command
java -version
You should get something similar to the following:
java version “1.6.0_12″
Java(TM) SE Runtime Environment (build 1.6.0_12-b04)
Java HotSpot(TM) Server VM (build 11.2-b01, mixed mode)
References
installing the latest jre on centos 5
AMTU Homepage
AMTU Forum – not much of use in there unfortunately
More…
Harald made a great post on the osCommerce forum that details the roadmap for the project and also includes some great links for developers who want to get involved.
I will definitely be forking the project and seeing what I might be able to contribute.
You can see the full post here.
This is the roadmap and feature list:
New Features
Some of the new features in osCommerce Online Merchant v3.0 Alpha 5 include:
* New object-oriented framework (alpha 1)
* New installation routine (alpha 1)
* register_globals and magic_quotes_gpc compatibility (alpha 1)
* New template structure implementation (alpha 1)
* Search-engine optimizations (alpha 1)
* Service modules (alpha 1)
* Checkout procedure cleanup (alpha 2)
* New language definitions implementation (alpha 2)
* Updated payment modules with post-transaction actions (alpha 3)
* Catalog front-end, administration tool, and installation routine combined (alpha 3)
* XHTML/CSS based default template layout for the catalog side (alpha 3)
* Multiple product images implementation (alpha 3)
* New action modules (alpha 3)
* Administration Tool access levels (alpha 4)
* Administrator Log (alpha 4)
* Administration Tool batch action capabilities (alpha 4)
* HTML Editor for product descriptions (alpha 4)
* Full zone entries for most countries (alpha 4; Anders Pamdal)
* Language injection feature for similar languages (alpha 4)
* GeoIP Modules for the Administration Tool Who’s Online section (alpha 4)
* Product Attributes and Product Variants implementation (alpha 5)
* Dynamic Table Listings (Administration Tool) (alpha 5)
* Live Search (Administration Tool) (alpha 5)
* Administration Tool sections now self-contained Applications (alpha 5)
* Error Logging; both PHP and MySQL errors and warnings now logged (forced runtime usage of PHP E_ALL and MySQL STRICT_ALL_TABLES) (alpha5)
* Stabilized Framework (alpha 5)
* Usage of JSON for RPC calls (alpha 5)
* Inclusion of jQuery v1.3.2 and jQuery UI v1.7 (alpha 5)
osCommerce Online Merchant v3.0 Roadmap
The roadmap leading up to the final v3.0 release is defined as:
osCommerce Online Merchant v3.0 Beta 1
* HTML E-Mails
* Purchase Without Account
* Frozen Framework
* Updated Frontend/GUI
* Upgrade from v2.2 and v3.0 Alpha 5
osCommerce Online Merchant v3.0
* Finalize Updated Frontend/GUI
* Documentation
* Certified Modules
* Upgrade from v2.2 and v3.0 Beta 1
osCommerce Online Merchant v3.1
* Backup/Import/Export Features
osCommerce Online Merchant v3.2
* Gift Vouchers and Coupons
More…
Harald has released some info about the minimum requirements of osCommerce version 3 alpha on the osCommerce blog here.
It requires PHP 5.2 as a minimum (though I would personally recommend avoiding version 5.2.0 and going for the latest version if at all possible.
The major reasons for this are the requirement for the object oriented mysqli interface for PHP and MySQL. It also requires PHP’s JSON encode functions.
JSON is a javascript data format a bit like XML or similar. It is used a lot of Web 2.0 style projects with a lot of asynchronous data transfers.
This indicates that we can expect some nice Javascript based asynchronous tools that will hopefully be faster and easier to use than the current osCommerce.
osCommerce is without a doubt one of the most popular open source ecommerce platforms and it is going to be really interesting to see how this new version compares with Magento.
As a long time user, hacker and fan of osCommerce I really wish them all the best of luck.
More…
If you are scratching your head trying to figure out why your Magento is not sending out newsletter emails then this post is what you need.
Magento has a script called cron.php which handles all of the timed jobs that your Magento store has to do. In this list is the task of sending out newsletters. You have to set up your server crontab to run this cron.php script at regular intervals (eg 5 minutes).
Once you do this, you should find that your newsletter will be sent out as expected.
See this page for some instructions
However – here are my simple instructions for a linux server.
1. Open up an SSH session with your server. (If you can’t do this you are going to have to ask your hosts to do this for you instead).
2. Browse to the document root of your magento store, the folder with cron.php in there
3. enter the command
pwd
This command gives you the current full path. Write this down somewhere
4. enter the command
which php
This command gives you the path to your PHP binary. Write this down somewhere
5. enter the command
crontab -e
This opens up your crontab editor which is the system for scheduling tasks on Linux
6. hit the [i] key to go into insert mode on the crontab editor (vi basically)
7. on a new line paste the following, but replacing the paths with the paths you got before
*/5 * * * * /path/to/php -f /path/to/cron.php
8. Hit [esc] then type the command
:wq
This saves the crontab
9. Create a newsletter and schedule it to send in 2 minutes time.
It should send. If it doesn’t then something else is wrong, but hopefully this should fix it for you.
More…
