Connecting Sqldeveloper to remote DB servers via Putty SSH Tunnels

Security Best Practice
As part of your security best practices, your ecommerce database server should not be accessible remotely (across the internet or WAN). For example, assuming standard ports, your firewall should block port 1521 for Oracle and port 3306 for MySQL.

There is no need for customers to access your database directly. Applications running locally on the box should access the DB on behalf of the customer.

Secure Remote DB Access by Developers and DBA via PuttySSH Tunnels
While standard ports are blocked, it may still be necessary for Developers and DBAs to access the DB server remotely and do so securely if they have SSH access to the remote server.

PuttySSH Configuration
The following shows PuttySSH configuration setup to use SSH Tunnel or port forwarding to create a seemingly local access securely to Oracle and MySQL DB servers running on a remote host.

1. Run Putty.exe to bring up the config dialog:

2. Select Tunnel

3. Oracle Tunnel setup: For source port enter 127.0.0.1:1521 and for Destination enter 127.0.0.1:1521
Enable Local radio button and Click Add

4.  MySQL Tunnel setup: For source port enter 127.0.0.1:3306 and for Destination enter 127.0.0.1:3306 then Enable Local radio button.

5. Click Add

6. Select Session on the left pane.  In Host Name or IP address enter the IP address of the remote server where both the Oracle and MySQL servers are running. Port is 22 for SSH.  Name this session Oracley-MySQL-Tunnel1
Click Save. Then Click Open

7. Login to the remote DB server with valid credentials to start the Oracle and MySQL secure tunneling. Once logged in, you will be ready for "local" secure tunneled-access to the Databases with your applications provided they are configured to make use of the local access. 

Next section will show sample application e.g. Sqldeveloper setup to access the remote databases locally.

Sqldeveloper Remote Database Local Access Configuration

1. In Sqldeveloper, Right-click on Connections, Select New Connection as shown

2.For Oracle, select Oracle tab. Enter Username/Password, Hostname and Port. 

Most important is to note and be sure that we are now using localhost (or 127.0.0.1) as the hostname instead of the Oracle DB remote server's hostname or IP address.  This is the point of tunneling, that we set up earlier, allowing us to connect and access the remote DB as if tt was running locally.Test the connection by clicking on Test button and you should see Status : Success (lower left side) as shown provided the PuttySSH tunnel window that you started earlier is still active.

3.The setup for MySQL connection is similar.  Click on the MySQL tab and enter connection parameters.

Again, using the SSH tunel set up earlier, note the use of localhost (or 127.0.0.1) as the Hostname instead of the MySQL DB remote server's hostname or IP address.  Test the connection successfully and Save it.

Additional Info:
If you do not see or cannot select MySQL tab in Step 3 above, it is most likely because you have not integrated a suitable MySQL connector with your Sqldeveloper installation. You can easily resolve this issue - you can add MySQL connection to your Sqldeveloper installation by following straightforward instructions compiled earlier by MySQL DBA in Installing and Configuring Oracle SQL Developer with MySQL

php build - undefined reference to php_glob_stream may be resolved with make distclean

Problem Description:

While building php-5.3x for use with apache  http server, we followed a successful

# ./configure --enable-option ...

with

# make

But the make failed.  After deploying what we thought should fix the make problem we reran configure  successfully again; but make failed with a different error output.  Here is the tail end error output (yours may be similar if not same):

..............................sevelra lines omitted.........
/Stage/php-5.3.5/ext/spl/spl_directory.c:168: undefined reference to `php_glob_stream                                          _ops'
/Stage/php-5.3.5/ext/spl/spl_directory.c:169: undefined reference to `_php_glob_strea                                          m_get_path'
ext/spl/.libs/spl_directory.o: In function `spl_filesystem_object_get_debug_info':
/Stage/php-5.3.5/ext/spl/spl_directory.c:579: undefined reference to `php_glob_stream                                          _ops'
ext/spl/.libs/spl_directory.o: In function `zim_spl_GlobIterator_count':
/Stage/php-5.3.5/ext/spl/spl_directory.c:1460: undefined reference to `php_glob_strea                                          m_ops'
/Stage/php-5.3.5/ext/spl/spl_directory.c:1461: undefined reference to `_php_glob_stre                                          am_get_count'
ext/standard/.libs/basic_functions.o: In function `zm_startup_basic':
/Stage/php-5.3.5/ext/standard/basic_functions.c:3651: undefined reference to `php_glo                                          b_stream_wrapper'
ext/zip/.libs/php_zip.o: In function `php_zip_add_from_pattern':
/Stage/php-5.3.5/ext/zip/php_zip.c:1632: undefined reference to `php_zip_glob'
/Stage/php-5.3.5/ext/zip/php_zip.c:1634: undefined reference to `php_zip_pcre'
main/streams/.libs/plain_wrapper.o: In function `php_plain_files_dir_opener':
/Stage/php-5.3.5/main/streams/plain_wrapper.c:857: undefined reference to `php_glob_s                                          tream_wrapper'
/Stage/php-5.3.5/main/streams/plain_wrapper.c:857: undefined reference to `php_glob_s                                          tream_wrapper'
collect2: ld returned 1 exit status
make: *** [sapi/cli/php] Error 1

How we fixed the Problem:
To fix the problem try
# make clean

Then run
#make distclean

Actually 'make clean' is a subset of 'make distclean'.  So just running 'make distclean' should be
enough.  After the make distclean, we reran 'configure' and then 'make'  and all was well again.  Apparently the 'make distclean' ensured we got rid of all previous build objects so that a new build with our fixes and adjustments contained only objects that are consistent with each other.

The takeaway is this: If you have previously ran 'make' or 'make install' then always run 'make distclean' if you make any changes such as library, include header, '--with-package', '--enable-package', etc., changes before you rebuild from the 'configure' step.  Hope this helps.

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.

A Solution for "debug source display has encountered a problem..."

It is one thing to follow SEO experts and Google suggestions for creating great content to bring traffic—customers to your estore. That's the first part of the equation. When she/he arrives we have to work hard to make the shopping easy to do and fast responding so that the customer will have a pleasant experience getting the Good Deal and Great $Price on the Supplies they came for.

To optimize a set of managed supplies shops for improved user-experience, I have downloaded, installed & configured eclipse PDT for Windows 2003 Server and xdebug for RedHat Linux El 5 64bit. Both are test servers.

The purpose of this quick log, and perhaps a reason why you have landed here, is to share my observation and a possible diagnosis/solution when you get a message like "debug source display has encountered a problem..." when using eclipse PDT and xdebug to debug your php web applications.

First here are the relevant specs for our environment in case they match or don't match your environment. In order words our solution may or may not help you. We hope it will.

Eclipse PDT Platform

Windows Server 2003 for Small Business Server SP2
Eclipse PDT Build 20090920-1017

Xdebug Platform

Linux 2.6.18-128.1.1.el5 SMP x86_64 x86_64 x86_64 GNU/Linux
Xdebug v2.0.5

A Solution for You?
After double-checking that xdebug has been installed and configured properly, it was discovered that the eclipse pdt platform was using IBM version of the Java system. It turns out that the Windows 2003 server is also hosting IBM Tivoli Directory Integrator (TDI V6.1.1) and IBM Websphere Application Server (WAS V6.1) which rely on IBM Java 1.5.

A fresh Java system was downloaded. The version downloaded was Version 6 Update 16. The installation was a breeze. After the installation, it was ensured that the new Java will be used for eclipse pdt operations by doing the following:

1. Set JAVA_HOME as a System Variable (see picture below)












2. Reinstall the Eclipse PDT

3. Restart Eclipse and configure your workspace accordingly with the newly installed Java

We are now able to debug and the steps seem to have resolved the problem: "debug source display has encountered a problem..."