MAP Direction

Not What You Think
About this entry. It is not what you're thinking. We are not talking about the traditional map like the one shown here with which you find a location or from which you get a direction.  Rather, this is a web issue that affects all e-commerce participants viz., product manufacturers, product distributors, product dealers (aka retailers), and shoppers (the product end users).  This common issue of interest is the Minimum Advertised Price (MAP).  It came up as a discussion topic last week.  Very interesting and productive discussion, from which I got among other things, this topic idea. The previous post was a necessarily long troubleshootng report; this time, this post will be a short one, much shorter than the last one.  Because it is an ongoing issue, I would welcome your opinion and insights on this topic.  You will get full credit for your comments and opinions ie., if you have a link, you can be sure it is (it will be) a "do-follow" link.

Quick Definitions
Here is a quick definitions set of the terms that may be used in this post
MAP       -Minimum Advertised Price
MSRP     -Manufacturer's Suggested Retail Price (also sometimes denoted as List Price)
MRP       -Minimum Retail Price

MAP is supposed to Level the Playing Field
Ideally, MAP should level the playing field for sellers.  If retailers R1, R2, R3, ..., Rn sell the product for the same price $P then one important way to compete and perhaps the difference that makes the difference for the customer's buy decision is customer service and comparatively better user-experience of the winning store.  A situation like this would definitely be great for customer service as the price factor (retailers trying to outdo each other undercutting prices) would no longer be an issue.

The Problem with MAP

However, the reality is that the MAP policy is not consistently and uniformly enforced by manufacturers. Reasons we've heard for this include the fact that the manufacturer doesn't have enough personnel to monitor and enforce the policy, or that the manufacturer's big accounts oppose the price level.  Whatever the reasons, the policy is certainly not consistently enforced for now.  If manufacturers are not going to do away with MAP policy, we at least hope they would improve their efforts to applying it unformly as  time progresses.  What are your thoughts? Any uniform enforcement ideas for the manufacturers?

Another problem is inconsistent interpretation.  According to information available on the internet, some manufacturers say the MAP is just the list price or MSRP and that the final sale price may be different from the display price. Others insist that the MAP is (and should be) Minimum Retail Price (MRP), ie., the final price cannot be less than the MAP value and bundling or any other promo incentive is not even allowed as part of the sale. 

Having Problems Installing xdebug on your eCommerce Test Server?

Quick description or summary of benefits of xdebug

If you are reading this, you have installed xdebug or are in the process of installing it because it is a useful web development debug tool for php based web applications.  I cannot sing the praises enough about the benefits.  Hear it, read the benefits of xdebug from a more authoritative source.


Our Problem & Troubleshooting may Help you Resolve yours

Just like you, we decided to employ xdebug to debug & resolve a nagging problem.  The following is a quick description of how we got to the point of wanting a debugger like xdebug, the installation issues and how we resolve them for our benefit.

How we got to wanting to use xdebug
 A customer who bought a Genesis crossbow from our Compound Crossbows Catalog wrote us that they liked our great price, better overall value shopping system, and would like to buy from us again when shopping for a range finder.  He wondered for himself and for our marketing strategy if we offer free shipping.  To him, we.responded that indeed we do  have free shipping in addition to our everyday Great $Price+Quick Shipping.  However, while we are 100% committed to better overall value for all of our customers, we do not use free shipping as a marketing gimmick whereby the other stores include double the price of shipping in the product price and then turn around touting free shipping.  Because we do pay the shippers (FedEx,  USPS,  or UPS) postage charges including insurance, and because our inexpensive prices translate to very thin profit margins, we have instructed our shipping calculator to algorithmically offer free shipping to customers when the price/weight combination of their cart items would put more money in the customer's pocket without putting us in the red.  We then told him that because of  this programmatic approach, rather than a blanket statement of free shipping, it is possible that the customer will be offered free ground shipping, or free 2 day expedited shipping or even free overnight expedited shipping depending on the price/weight combo mentioned before.  We then asked him to try it to see for himself even if he was not ready to get his range finder yet.  The customer called us two days later saying there was no free shipping no matter any priced item he added to the cart.  We reviewed our shopping cart shipping settings and configurations and they were properly configured—and there is no reason why free shipping should not be offered at the correct price/weight combos.  To cut the long story short, this is what prompted us to invoke a debugger to try to trace the steps and find out why the expected  free shipping offers were not appearing as expected.

Enter the xdebug Utility
With a quick Google search for php debugger we settled on xdebug as we judged it woild perfectly meet our need.  We then proceeded to download and install it.  The following is a summary of the installation problems and how we overcame it


Our xdebug Installation Problem and Resolution
Here is a quick spec of our test server where of course this utility is now installed. 

RedHat 5:
#cat /proc/version
Linux version 2.6.18-128.1.1.el5 (mockbuild@ls20-bc2-14.build.redhat.com) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-44)) #1 SMP Mon Jan 26 13:58:24 EST 2009

#uname -a
Linux lagos 2.6.18-128.1.1.el5 #1 SMP Mon Jan 26 13:58:24 EST 2009 x86_64 x86_64 x86_64 GNU/Linux

1st problem - pecl is not there:

#pecl install xdebug

-bash: pecl: command not found

Because pecl not installed or not in the command path. most likely, pecl is not installed. pecl is part of the php development package. Development packages such as this including compilers should not be installed on production servers for security reasons. pecl and pear go together.  We went back to the net to install php dev package: Install php development package:

Install pear:

#wget "http://pear.php.net/go-pear"

After the download, verify that go-pear is in the current dir, then:

#php go-pear

Next add the bin directory to PATH and then confirm that pecl is also installed and available with pear with:

#pecl

which will give a list of usage commands and options if installation was correct.


2nd problem pecl not installing xdebug:
We attempted to install xdebug like this with the following output:

#pecl install xdebug
downloading xdebug-2.0.5.tgz ...
Starting to download xdebug-2.0.5.tgz (289,234 bytes)
.................done: 289,234 bytes

Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 92160 bytes) in /var/PEAR/PEAR/PackageFile/v2/Validator.php on line 170
#

We at first thought to adjust the memory linit in php.ini.  And as we later found out adjusting memory limit in php.ini will not help because pecl does not use the php.ini config file to set memory limit

Also, instead of having to hack Validator.php (who knows what other problems that may bring?), we tried to install it (xdebug) this way with the following output:

#pecl download xdebug
downloading xdebug-2.0.5.tgz ...
Starting to download xdebug-2.0.5.tgz (289,234 bytes)
.................done: 289,234 bytes
File /xdebug-2.0.5.tgz downloaded

xdebug file we then next try to install it with pear since we have pear by now.  Note, like us, you should specify full filename this time instead of just the package name ie., xdebug-2.0.5.tgz instead of xdebug:

#pear install xdebug-2.0.5.tgz
67 source files, building
running: phpize
sh: phpize: command not found
ERROR: `phpize' failed

which brings up the
3rd problem: phpize not there!

If you get this error above, what you need, as we found out, is php-devel package which was not provided by RHN for our el5. However, we found out that the x87_64 arch from Cent OS was acceptable and you too should try it.  Here are some guiding steps:...

Do uname -a to get release version info

#uname -a
Linux hostname 2.6.18-128.1.1.el5 #1 SMP Mon Jan 26 13:58:24 EST 2009 x86_64 x86_64 x86_64 GNU/Linux

Then see the version of the current php pckgs since the devel version must be at the same level to avoid problems.

#rpm -q --all | grep php
php-mysql-5.1.6-23.2.el5_3
php-pdo-5.1.6-23.2.el5_3
php-5.1.6-23.2.el5_3
php-cli-5.1.6-23.2.el5_3
php-ldap-5.1.6-23.2.el5_3
php-common-5.1.6-23.2.el5_3

Your output may be different from ours, but the idea is to verify the version level to be able to execute the next steps successfully.  Based on the above output we then got the equivalent version using

#wget "http://mirror.centos.org/centos/5/updates/x86_64/RPMS/php-devel-5.1.6-23.2.el5_3.x86_64.rpm"
--09:20:14-- http://mirror.centos.org/centos/5/updates/x86_64/RPMS/php-devel-5.1.6-23.2.el5_3.x86_64.rpm
Resolving mirror.centos.org... 66.109.26.212
Connecting to mirror.centos.org|66.109.26.212|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 514033 (502K) [application/x-rpm]
Saving to: `php-devel-5.1.6-23.2.el5_3.x86_64.rpm'

100%[==============================================================>] 514,033 68.2K/s in 6.8s

09:20:21 (74.4 KB/s) - `php-devel-5.1.6-23.2.el5_3.x86_64.rpm' saved [514033/514033]

Once you have the correct version, install it:

#rpm -ihv php-devel-5.1.6-23.2.el5_3.x86_64.rpm
warning: php-devel-5.1.6-23.2.el5_3.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID e8562897
Preparing... ########################################### [100%]
1:php-devel ########################################### [100%]

After the installation, we verify that it is okay as follows from the top level source directory of the module:

#/usr/bin/phpize

If the above commands displays a warning or a message, it can be ignored as we found out.

Now try to re-install xdebug (again) and verify the good news as it progresses to completion successfully:

#pear install xdebug-2.0.5.tgz
67 source files, building
running: phpize
Configuring for:
PHP Api Version: 20041225
Zend Module Api No: 20050922
Zend Extension Api No: 220051025
building in /var/tmp/pear-build-root/xdebug-2.0.5
running: /var/temp/xdebug/configure
checking for egrep... grep -E
checking for a sed that does not truncate output... /bin/sed
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking whether gcc and cc understand -c and -o together... yes
checking if compiler supports -R... no
checking if compiler supports -Wl,-rpath,... yes
checking build system type... x86_64-redhat-linux-gnu

................Several output lines omitted................

Libraries have been installed in:
/var/tmp/pear-build-root/xdebug-2.0.5/modules

If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the `-LLIBDIR'
flag during linking and do at least one of the following:
- add LIBDIR to the `LD_LIBRARY_PATH' environment variable
during execution
- add LIBDIR to the `LD_RUN_PATH' environment variable
during linking
- use the `-Wl,--rpath -Wl,LIBDIR' linker flag
- have your system administrator add LIBDIR to `/etc/ld.so.conf'

..........................More output lines omitted...............

Build process completed successfully
Installing '/usr/lib64/php/modules/xdebug.so'
install ok: channel://pecl.php.net/xdebug-2.0.5
configuration option "php_ini" is not set to php.ini location
You should add "extension=xdebug.so" to php.ini

 Congratulations for Problem Resolved if you see the last line
That's it. You're ready to use xdebug.  Well, almost ready.  Notice the last line. Very important. Add it to your php.ini to really complete the install and be ready to use it:.

extension=xdebug.so

Please see xdebug home for latest updates and configuration info.

PS: With xdebug, we quickly found our free shipping issue and fixed it.  It turned out that as soon as the shipping & handling charge was set to 0.0, the first expression after the loop was setting the shipping back to the original amount that was saved. Silly, eh?  It happens occasionally. 

Kudos to MSFT for Real Time Files Monitor - Windows XP Security

Acronyms & Abbreviations
SP2 - Service Pack 2
WTM - Windows Task Manager
WFP - Windows File Protection
CPU - Central Processing Unit
MSFT - Microsoft

Introduction
One of our test computer systems is running Windows XP SP2 and was running sluggishly recently. When we looked at the WTM system processes display, the application/process wuauclt.exe was running "fast and furious", essentially controlling the CPU time. A quick web search indicate that this program is a standard Windows application that has occasionally been a source of concern to other users. Because of our issue - a sluggish test box - and because the task manager was pointing to this application as the one that may be causing the problem, we decided to delete the program anyway.

The "Discovery"
It was during the deletion process that we discovered what we hadn't noticed before, what had been quietly working as a security measure all along - the Windows File Protection facility. Here is the sequence of events:

1. Searched and found all the occurrences of  wuauclt*.*  Our search returned:
   WINDOWS\system32\dllcache\wuauclt.exe
   WINDOWS\ServicePackFiles\i386\wuauclt.exe
   WINDOWS/system32\wuauclt.exe
   WINDOWS\system32\wuauclt1.exe
2. In the WTM, the wuauclt.exe process was ended
3. The files returned in Step 1 above were deleted
4. Then pops up a message box titled Windows File Protection: Files that are required for Windows to run properly have been replaced by unrecognized versions... See image below.









When we clicked Cancel, the following message box appeared:









The Take Away
While we decided to delete and not restore as prompted on this occasion, the take away for us is the comfort to know that the Windows File Protection exists and is working near real time to monitor essential OS files. This is a good security measure and for it Kudos to MSFT. While we have not spent time to fully understand the full functions of protection facility, it is safe to infer, based on this encounter, that an attacker (malware) cannot easily overwrite or delete any file under the WFP facility without being logged or without the action generating an alert; hence the malware will have to write to a different directory or use a different filename.

Apache: Could not reliably determine server's fully qualified name

Full Error Message:

Starting httpd: httpd: apr_sockaddr_info_get() failed for
httpd: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1 for ServerName

What Led to This
This came out of the blue. We did not implement a configuration change in apache. We only changed the root passwd in mySQL database. To do this, we had to stop the database server and momentarily run in the safe mode. And since the database server was going to be offline temporarily we judged it wise to also shutdown the web server.

After restarting the mySQL server successfully, we naturally restarted the webserver:

#/etc/init.d/httpd start
Starting httpd: httpd: apr_sockaddr_info_get() failed for
httpd: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1 for ServerName
[ OK ]

As you see, the server started but it complained about the fully qualified domain name not determinable.

Troubleshooting
Top shows that the server OS has been up for 106 days continuously. So no one has restarted with a changed kernel.

Then we ran hostname command to see what value the server OS had.

hostname returned blank
uname -n also returned blank

However, looking at the contents of /etc/sysconfig/network we were surprised with what we saw:

#cat /etc/sysconfig/network
HOSTNAME=u15334762.onlinehome-server.com
NETWORKING=yes
NOZEROCONF=yes

That is, there is no reason why there should be no configured hostname. A solution based on this is to just reboot the server and it will pick up the hostname in /etc/sysconfig/network and perhaps cure other ills we don't yet know about. But we decided against this nuclear option. In the UNIX/Linux production environment, one should only reboot if and only if there is no other option.

The Solution
We decided to refresh the hostname by using the Linux sysctl command:

#sysctl kernel.hostname=u15334762.onlinehome-server.com

Then, we verified that the re-setting was accepted:

#sysctl kernel.hostname
kernel.hostname = u15334762.onlinehome-server.com

Also, hostname and uname were used for confirmation:

#hostname
u15334762.onlinehome-server.com

#uname -n
u15334762.onlinehome-server.com

Finally, we restarted the web server and all was (is) well again:

#/etc/init.d/httpd restart
Stopping httpd: [ OK ]
Starting httpd: [ OK ]

Note, when you checkout "u15334762.onlinehome-server.com" the browser will take you to "http://www.paintball-gear-supplies.com/". If you're in the USA, as the store does not currently ship Internationally, you will get Great $Prices on Camping Gear, Paintball Supplies, Riflescopes and Hunting Accessories. Best overall value, when you compare prices with shipping - the total cost of the order from the warehouse to your door.