Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much

CGI script connecting via terminal but not via browser

by nkrgupta (Novice)
on Sep 18, 2012 at 08:40 UTC ( #994237=perlquestion: print w/replies, xml ) Need Help??
nkrgupta has asked for the wisdom of the Perl Monks concerning the following question:


I can easily connect to a remote MySQL server using the DBI module in my Perl scripts. However, when I try to use the same connection settings/properties from within a CGI script AND call it via browser, the MySQL connection fails to establish.

There are no helpful errors/warnings being logged either in the apache error log, or the browser, in spite of using

use CGI::Carp qw(warningsToBrowser fatalsToBrowser);

I'm getting the following error:

 DBI connect('$db_name:$remote_host_IP:$port','$username',...) failed: Can't connect to MySQL server on '$remote_host_IP' (13) at /var/www/cgi-bin/$script_name.cgi line 25

Of course the logs contain the actual values of the abovementioned variables

I'm using the following connection string

$dbh = DBI->connect($ds, $uname, $pwd,{RaiseError => 1 }) or die "$DBI::errstr Could not connect: $!<br>";

Strangely, the exact same CGI script works fine when executed from the terminal (from within same cgi-bin directory), even after sudo'ing to the apache/tomcat user

On the other hand, phpMyAdmin works great on the machine, connecting to a different MySQL server on localhost.

I'm using CentOS Release 5.8. However, before writing the scripts, I had to install mysql server and client from a third-party repository via yum, because CentOS would not update PHP and the related php-mysql library to 5.2 or higher, for which a mysql upgrade was necessary (which also could not be done under my setup).

Which environment variables/libraries can I further look into to debug this issue?

Thanks a lot

Replies are listed 'Best First'.
Re: CGI script connecting via terminal but not via browser
by moritz (Cardinal) on Sep 18, 2012 at 09:47 UTC

    Maybe there's a security system like selinux or AppArmor active that assigns the web server process a different security context than merely sudo'ing into the apache user?

    Such a security context could very well prevent it from opening a network connection to another host.

    So please consult your system administrator, or if you are your own administrator, read up on security systems.

      Thanks moritz.

      I am reading up on selinux now which seems to be enabled on my system, and might be a possible cause. The log file at /var/log/audit/audit.log shows the following entry among other

      type=AVC msg=audit(1347964714.394:62458): avc:  denied  { name_connect } for  pid=14917 comm="my_script.cgi" dest=3306 scontext=root:system_r:httpd_sys_script_t:s0 tcontext=system_u:object_r:mysqld_port_t:s0 tclass=tcp_socket

        Fixed it! It was indeed a selinux issue, which by default was preventing httpd to establish network connections.

        Had to run the following command to allow it to do so

        setsebool -P httpd_can_network_connect=1

        Once again, thanks a lot moritz. I thought it might have to do with security settings, just didn't know where to look!

Re: CGI script connecting via terminal but not via browser
by aaron_baugher (Curate) on Sep 18, 2012 at 09:54 UTC

    Oops, never mind my original answer; I missed the line where you said the actual variables were filled in there.

    It would seem there's a difference in the environment when it's run as a CGI by apache. You can compare by writing a simple CGI that reports on the environment and info on perl, like this:

    #!/bin/sh perl -v echo ============================= set echo ============================= whoami echo ============================= pwd

    Running that from the terminal and through a browser should help you spot any differences that might affect your script. The perl -v line especially will show if your script could be picking up different modules in either case.

    Aaron B.
    Available for small or large Perl jobs; see my home node.

      Thanks Aaron. The Perl version is the same on both environments (5.8.8), however the PATH variable is significantly different:

      in CGI

      PATH == /sbin:/usr/sbin:/bin:/usr/bin

      in shell

      PATH == /usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin:/usr/eclipse/eclipse:/usr/local/apache-maven/apache-maven-2.2.1/bin:/usr/java/jdk1.6.0_34//bin

      Any of the paths missing in CGI could be causing this?

      Also, I have the following variable in shell, but not in CGI

      TOMCAT_HOME   ==   /usr/share/tomcat6/

        The PATH environment variable only affects which perl executable is used, if there happens to be more than one on the system. For instance, if you have /usr/local/bin/perl and /usr/bin/perl, the former will be picked up first by your shell, while the latter is used by your CGI. Two different perls, even if the same version, could have two different sets of modules and configurations. You could add which perl to my test CGI to report the full pathname of perl, and the results of perl -v will also show any differences in configs and the paths that perl checks for modules. If those match, then PATH doesn't matter beyond that.

        Aaron B.
        Available for small or large Perl jobs; see my home node.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://994237]
Approved by Corion
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others cooling their heels in the Monastery: (6)
As of 2018-06-20 15:16 GMT
Find Nodes?
    Voting Booth?
    Should cpanminus be part of the standard Perl release?

    Results (116 votes). Check out past polls.