Loading ...
Sorry, an error occurred while loading the content.

Am I running mod perl 2?

Expand Messages
  • Shane De Jager
    Hi, I have just recently moved form regular CGI to mod perl 2. After configuring am am not 100% sure am am actually running mod_perl. I did a CGI the CGI test
    Message 1 of 9 , Jul 18, 2005
    • 0 Attachment
      Hi,

      I have just recently moved form regular CGI to mod perl 2. After configuring am am not 100% sure am am actually running mod_perl. I did a CGI the CGI test shown in "Practical Mod_Perl". According to it the GATEWAY_INTERFACE variable should say CGI-Perl/1.1 but mine says CGI/1.1. What confuses me is that the MOD_PERL Variable says mod_perl/2.0.1. Say am I really running mod_perl?

      --
      Shane De Jager
      Technical Developer

      INTERGAGE
      High-performance, updateable Web sites

      Switchboard +44(0)845 456 1022
      Direct Dial +44(0)1202 688 219
      ==
      www.intergage.co.uk
      sdejager@...

      Are you aware of our referral scheme? Learn how you could profit personally from passing us leads.

      Click here to pass a referral: www.intergage.co.uk/referrals
    • Geoffrey Young
      ... the behavior of GATEWAY_INTERFACE changed between mod_perl 1.0 and 2.0, so don t really worry about that for mp2. if $ENV{MOD_PERL} is true you re running
      Message 2 of 9 , Jul 18, 2005
      • 0 Attachment
        Shane De Jager wrote:
        > Hi,
        >
        > I have just recently moved form regular CGI to mod perl 2. After
        > configuring am am not 100% sure am am actually running mod_perl. I did a
        > CGI the CGI test shown in "Practical Mod_Perl". According to it the
        > GATEWAY_INTERFACE variable should say CGI-Perl/1.1 but mine says CGI/1.1.
        > What confuses me is that the MOD_PERL Variable says mod_perl/2.0.1. Say
        > am I really running mod_perl?

        the behavior of GATEWAY_INTERFACE changed between mod_perl 1.0 and 2.0, so
        don't really worry about that for mp2.

        if $ENV{MOD_PERL} is true you're running under mod_perl.

        --Geoff
      • Dominique Quatravaux
        ... Hash: SHA1 ... Sorry to be rude about this, but no. This *needs* fixing. http://marc.theaimsgroup.com/?l=apache-modperl&m=112005579327997&w=2 - --
        Message 3 of 9 , Aug 1, 2005
        • 0 Attachment
          -----BEGIN PGP SIGNED MESSAGE-----
          Hash: SHA1

          Geoffrey Young wrote:

          > if $ENV{MOD_PERL} is true you're running under mod_perl.

          Sorry to be rude about this, but no. This *needs* fixing.

          http://marc.theaimsgroup.com/?l=apache-modperl&m=112005579327997&w=2

          - --
          Dominique QUATRAVAUX Ingénieur senior
          01 44 42 00 08 IDEALX

          -----BEGIN PGP SIGNATURE-----
          Version: GnuPG v1.2.5 (GNU/Linux)
          Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

          iD8DBQFC7cuPMJAKAU3mjcsRAqepAJ9CJtTg08g08ApGf1mzFjNadnNZMgCgtZPs
          zX5nPNJ4Osh3ruy4BptydsY=
          =Nf7n
          -----END PGP SIGNATURE-----
        • Philip M. Gollucci
          ... Okay So I read this thread. Whats wrong with: (from your own post) ... Why is that not trustworth ? Are you saying you want a onliner function to return
          Message 4 of 9 , Aug 1, 2005
          • 0 Attachment
            Dominique Quatravaux wrote:
            > -----BEGIN PGP SIGNED MESSAGE-----
            > Hash: SHA1
            >
            > Geoffrey Young wrote:
            >
            >
            >>if $ENV{MOD_PERL} is true you're running under mod_perl.
            >
            >
            > Sorry to be rude about this, but no. This *needs* fixing.
            >
            > http://marc.theaimsgroup.com/?l=apache-modperl&m=112005579327997&w=2
            Okay So I read this thread.

            Whats wrong with: (from your own post)
            >$mod_perl2::VERSION skips these drawbacks (it can only be altered from
            >Perl and is not inherited) but it is currently not trustworthy either:

            >$ perl -Mmod_perl2 -e 'print $mod_perl2::VERSION'
            >2.000001

            Why is that not trustworth ?

            Are you saying you want a onliner function to return the version string
            absolutely regardless of which mod_perl or mod_perls are installed.
            that would be:

            1.x
            <1.99022
            >=1.99023 (RC5)
          • Dominique Quatravaux
            ... Hash: SHA1 ... Thanks! ... Because we are obviously not *running* under mod_perl, but rather, from a command-line Perl interpreter. The $mod_perl2::VERSION
            Message 5 of 9 , Aug 1, 2005
            • 0 Attachment
              -----BEGIN PGP SIGNED MESSAGE-----
              Hash: SHA1

              Philip M. Gollucci wrote:

              > Okay So I read this thread.

              Thanks!

              >> $ perl -Mmod_perl2 -e 'print $mod_perl2::VERSION' 2.000001
              >
              > Why is that not trustworth ?

              Because we are obviously not *running* under mod_perl, but rather,
              from a command-line Perl interpreter. The $mod_perl2::VERSION method
              might be considered trustworthy enough for checking which version
              (assuming singular!) of mod_perl is *installed*, but nobody cares
              about that. One typically wants to know what version is *running* in
              the current interpreter, in order to adjust behavior accordingly.

              Case in point: when using Apache::DB from mod_perl 1.3 with mod_perl
              2.0 also installed on the same system, the following code (actual
              excerpt from Apache/DB.pm) obviously goes SNAFU.

              use constant MP2 => eval { require mod_perl2; $mod_perl::VERSION >
              1.99 };

              Things get worse if I e.g. want to make some code interoperable
              between standalone CGI and ModPerl::Registry (most likely the intent
              of the original poster in the current thread). Then my admittedly
              bizarre situation of having two mod_perls installed becomes irrelevant
              to the issue at hand. Even with a single, up-to-date mod_perl 2
              installed, any test based upon $mod_perl::VERSION would fail at
              discriminating between /usr/bin/perl and
              /usr/lib/apache2/modules/mod_perl.so. And $ENV{MOD_PERL} does not cut
              it either, for other reasons detailed in my previous post (wrong scoping).

              > Are you saying you want a onliner function to return the version
              > string absolutely regardless of which mod_perl or mod_perls are
              > installed.

              I would like a robust way of checking the mod_perl version (or lack
              thereof) of the *currently running* Perl interpreter. I did kludge up
              one, but it is rear-end ugly (see code at the end of my post in the
              other thread).

              Support from mod_perl itself (e.g. in the form of a running_version()
              XS sub) would be helpful and robust. Causing mod_perl2.pm to fail
              initialization when not running under mod_perl (using an XS detection
              kludge like mine, *not* $ENV{MOD_PERL}) would be a second best.

              - --
              Dominique QUATRAVAUX Ingénieur senior
              01 44 42 00 08 IDEALX

              -----BEGIN PGP SIGNATURE-----
              Version: GnuPG v1.2.5 (GNU/Linux)
              Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

              iD8DBQFC7k4eMJAKAU3mjcsRAik+AKCBp5LeeZlW97NL/a1g2/y9jeK4VACgn97F
              /Om91wZ9u06SS2k/dk3M7DM=
              =a8FK
              -----END PGP SIGNATURE-----
            • Philip M. Gollucci
              ... Okay, I at least understand what you are saying now. I think what you re getting at is that (other then ENV tampering) is that the websver once it sees and
              Message 6 of 9 , Aug 1, 2005
              • 0 Attachment
                Dominique Quatravaux wrote:
                > /usr/lib/apache2/modules/mod_perl.so. And $ENV{MOD_PERL} does not cut
                > it either, for other reasons detailed in my previous post (wrong scoping).
                Okay, I at least understand what you are saying now.

                I think what you're getting at is that (other then ENV tampering) is
                that the websver once it sees and successfully loads

                LoadModule perl_module modules/mod_perl.so

                $ENV{MOD_PERL}

                will be in your environment even if you happen to be running a REGULAR
                CGI from /cgi-bin on mod_cgi.

                Correct me if I'm wrong while I think about this more.
              • Joe Schaefer
                ... I like the second-best option, actually: IMO require mod_perl2 should throw an exception unless we re actually running under the mod_perl.so interpreter.
                Message 7 of 9 , Aug 1, 2005
                • 0 Attachment
                  Dominique Quatravaux <dom@...> writes:

                  > I would like a robust way of checking the mod_perl version (or lack
                  > thereof) of the *currently running* Perl interpreter. I did kludge up
                  > one, but it is rear-end ugly (see code at the end of my post in the
                  > other thread).
                  >
                  > Support from mod_perl itself (e.g. in the form of a running_version()
                  > XS sub) would be helpful and robust. Causing mod_perl2.pm to fail
                  > initialization when not running under mod_perl (using an XS detection
                  > kludge like mine, *not* $ENV{MOD_PERL}) would be a second best.

                  I like the second-best option, actually: IMO "require mod_perl2"
                  should throw an exception unless we're actually running under the
                  mod_perl.so interpreter. People that only care about the installed
                  version would just need to

                  eval {require mod_perl2};
                  if ($@) {
                  if ($@ =~ /^Can't locate mod_perl2/)
                  $have_modperl2 = 0;
                  elsif ($@ =~ /^Not running under mod_perl.so/)
                  $have_modperl2 = 1;
                  }
                  else {
                  # running under mod_perl.so
                  $have_modperl2 = 1;
                  }

                  --
                  Joe Schaefer
                • Joe Schaefer
                  ... I should have pointed out tho that a change like this certainly shouldn t happen in mp2.0. For better or worse, we chose to use $ENV{MOD_PERL} to signal
                  Message 8 of 9 , Aug 1, 2005
                  • 0 Attachment
                    Joe Schaefer <joe+gmane@...> writes:

                    > Dominique Quatravaux <dom@...> writes:
                    >
                    >> I would like a robust way of checking the mod_perl version (or lack
                    >> thereof) of the *currently running* Perl interpreter. I did kludge up
                    >> one, but it is rear-end ugly (see code at the end of my post in the
                    >> other thread).
                    >>
                    >> Support from mod_perl itself (e.g. in the form of a running_version()
                    >> XS sub) would be helpful and robust. Causing mod_perl2.pm to fail
                    >> initialization when not running under mod_perl (using an XS detection
                    >> kludge like mine, *not* $ENV{MOD_PERL}) would be a second best.
                    >
                    > I like the second-best option, actually: IMO "require mod_perl2"
                    > should throw an exception unless we're actually running under the
                    > mod_perl.so interpreter.

                    I should have pointed out tho that a change like this certainly
                    shouldn't happen in mp2.0. For better or worse, we chose to use
                    $ENV{MOD_PERL} to signal the runtime.

                    --
                    Joe Schaefer
                  • Dominique Quatravaux
                    ... Hash: SHA1 ... Part of the problem indeed. There are other practical problems (e.g. PerlSetupEnv Off used to disable $ENV{MOD_PERL} under mod_perl 1.3,
                    Message 9 of 9 , Aug 1, 2005
                    • 0 Attachment
                      -----BEGIN PGP SIGNED MESSAGE-----
                      Hash: SHA1

                      Philip M. Gollucci wrote:

                      > Okay, I at least understand what you are saying now.
                      >
                      > $ENV{MOD_PERL}
                      >
                      > will be in your environment even if you happen to be running a
                      > REGULAR CGI from /cgi-bin on mod_cgi.

                      Part of the problem indeed. There are other practical problems (e.g.
                      PerlSetupEnv Off used to disable $ENV{MOD_PERL} under mod_perl 1.3,
                      don't know if this is still the case). Also we may be invoking Perl
                      scripts from mod_perl using a piped open(), although we arguably could
                      mangle the %ENV by ourselves then.

                      Also the code purity department inside me thinks it's obvious that a
                      Perl notion (mod_perl version) should be materialized through a Perl
                      mechanism (variable or sub) instead of the UNIX env, but maybe that's
                      just me. No software library that I know of signals its version number
                      by setting an environment variable at program startup! Therefore the
                      whole $ENV{MOD_PERL} idea very much looks like a bad NCSA-legacy
                      thinko to me (mimicked from $ENV{GATEWAY_INTERFACE}, which *does*
                      actually make sense).

                      - --
                      Dominique QUATRAVAUX Ingénieur senior
                      01 44 42 00 08 IDEALX

                      -----BEGIN PGP SIGNATURE-----
                      Version: GnuPG v1.2.5 (GNU/Linux)
                      Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

                      iD8DBQFC7mZgMJAKAU3mjcsRAkhdAKCxT1MDpLTeRckPN67npCCmS2Oa8gCdE5dl
                      N7MRmpOdCMzfzWEbCqULZJI=
                      =lIm8
                      -----END PGP SIGNATURE-----
                    Your message has been successfully submitted and would be delivered to recipients shortly.