Page 1 of 3 123 LastLast
Results 1 to 10 of 24

Thread: Python scripts fail on 12.3

  1. #1
    Join Date
    Feb 2009
    Location
    Oxford, UK
    Posts
    12

    Default Python scripts fail on 12.3

    Hi All,

    I'm going slightly barmy trying to figure this out, having been round several Python fora and elsewhere. I am discussing this with the vendors, but I thought I'd try here and have another sting to my bow.

    I have a Ruckus Wireless system, and one of the means of providing access to it is to run a web-based portal provided by Ruckus that interfaces with the controller, and delivers a dynamic PSK to each user (each user gets a different PSK for our SSID) based on credentials the user supplies.

    These comprise a handful of html pages and three python scripts. Simples.

    Because our University provides Single Sign-On via the Shibboleth system, I figured I could drop the Ruckus portal software in a Shibboleth-protected directory on the web server, and pass the username and password to the wireless controller. I've configured the wireless controller to talk to a Radius server in our local network, which will just answer "YES" to valid usernames sent to it. Basically, a User will authenticate to Unversity SSO via Shibboleth, be passed to the local Wifi portal, which will send the username and a password to the Radius server via the wifi controller. If the username exists locally (in our AD) then the user is granted access to the wifi.

    The problem is that although a user can successfully authenticate to SSO via Shibboleth, the python scripts totally fail - even when providing a username and password manually (I haven't got round to feeding them data from the shibboleth session yet).

    The supremely irritating thing is that in my lengthy discussions with Ruckus (gong on since November) they've got it to work on their Linux test boxes, but they're using CentOS 6.

    I'm having to use something I can install Shibboleth on *and* which runs Python 2.7 - so that means OpenSuse 12.3 or Centos 6. I'm testing Centos build today, but it is somewhat different (understatement) to the installations I'm used to (SLES 11 and OpenSuse12/13). I can't test it with 13.1 as Shibboleth does not work on that system yet - the Apache module fails to load as there are dependencies that can't be provided.

    The error is as follows:

    MOD_PYTHON ERROR

    ProcessId: 15322
    Interpreter: 'gatekeeper.new.ox.ac.uk'

    ServerName: 'gatekeeper.new.ox.ac.uk'
    DocumentRoot: '/srv/www/htdocs'

    URI: '/cgi-bin/hotspot_login.py'
    Location: None
    Directory: '/srv/www/cgi-bin/'
    Filename: '/srv/www/cgi-bin/hotspot_login.py'
    PathInfo: ''

    Phase: 'PythonHandler'
    Handler: 'mod_python.cgihandler'

    Traceback (most recent call last):

    File "/usr/lib64/python2.7/site-packages/mod_python/importer.py", line 1537, in HandlerDispatch
    default=default_handler, arg=req, silent=hlist.silent)

    File "/usr/lib64/python2.7/site-packages/mod_python/importer.py", line 1229, in _process_target
    result = _execute_target(config, req, object, arg)

    File "/usr/lib64/python2.7/site-packages/mod_python/importer.py", line 1128, in _execute_target
    result = object(arg)

    File "/usr/lib64/python2.7/site-packages/mod_python/cgihandler.py", line 96, in handler
    imp.load_module(module_name, fd, path, desc)

    File "/srv/www/cgi-bin/hotspot_login.py", line 22, in <module>
    import xmlcommon

    ImportError: No module named xmlcommon

    - - -

    xmlcommon.py DOES exist in the same directory as hotspot_login.py (the python script that kicks the process off), and has the same permissions.

    If I start the Python interpreter from the command line, I *can* import that module - but it fails to do so when called from another python script in the same directory.

    Any pointers? I'm all out of ideas here.

    Cheers,
    James



  2. #2

    Default Re: Python scripts fail on 12.3

    On 2014-01-28, jhd10374 <jhd10374@no-mx.forums.opensuse.org> wrote:
    >
    > Hi All,
    >
    > I'm going slightly barmy trying to figure this out, having been round
    > several Python fora and elsewhere. I am discussing this with the
    > vendors, but I thought I'd try here and have another sting to my bow.


    It might well prove to be a `sting'!

    > I have a Ruckus Wireless system, and one of the means of providing
    > access to it is to run a web-based portal provided by Ruckus that
    > interfaces with the controller, and delivers a dynamic PSK to each user
    > (each user gets a different PSK for our SSID) based on credentials the
    > user supplies.

    <SNIP>
    > The supremely irritating thing is that in my lengthy discussions with
    > Ruckus (gong on since November) they've got it to work on their Linux
    > test boxes, but they're using CentOS 6.


    Most University Departments (including mine) who dabble in Linux know very little about distributions outside their
    Red-Hat based comfort zone. Sometimes it's just best to add another distro on your hard drive and conform along the
    paths of least resistence. If you can't bear that, consider installing Centos inside KVM inside openSUSE.

    > I'm having to use something I can install Shibboleth on *and* which runs
    > Python 2.7 - so that means OpenSuse 12.3 or Centos 6. I'm testing
    > Centos build today, but it is somewhat different (understatement) to the
    > installations I'm used to (SLES 11 and OpenSuse12/13).


    Build it? Why don't you just binary install it?

    > I can't test it
    > with 13.1 as Shibboleth does not work on that system yet - the Apache
    > module fails to load as there are dependencies that can't be provided.
    >
    > The error is as follows:


    If you want anyone other than NNTP users confined to console use to view the output, please surround it with code tags
    iconified by octothorpes.

    > File "/srv/www/cgi-bin/hotspot_login.py", line 22, in <module>
    > import xmlcommon
    >
    > ImportError: No module named xmlcommon
    >
    > - - -
    >
    > xmlcommon.py DOES exist in the same directory as hotspot_login.py (the
    > python script that kicks the process off), and has the same permissions.
    >
    > If I start the Python interpreter from the command line, I *can* import
    > that module - but it fails to do so when called from another python
    > script in the same directory.


    Have you tried adding the directory containing xmlcommon.py to your python path inside ~/.bashrc? e.g.

    Code:
    export PYTHONPATH=.:/home/user/path_to_xmlcommon/:PYTHONPATH

    > Any pointers? I'm all out of ideas here.


    I don't know anything about web-based coding (I don't even know html) and so I strongly suspect my suggestion won't
    work.


  3. #3
    Join Date
    Jun 2008
    Location
    Podunk
    Posts
    32,336
    Blog Entries
    15

    Default Re: Python scripts fail on 12.3

    On Tue 28 Jan 2014 03:36:01 PM CST, jhd10374 wrote:

    If I start the Python interpreter from the command line, I *can* import
    that module - but it fails to do so when called from another python
    script in the same directory.

    Any pointers? I'm all out of ideas here.

    Cheers,
    James


    Hi
    So the beginning of the script calls all the imports os sys etc?

    You might have to add some debug to the scripts so it tells you where
    it's looking when it trys to import the module.

    --
    Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
    openSUSE 13.1 (Bottle) (x86_64) GNOME 3.10.2 Kernel 3.11.6-4-desktop
    If you find this post helpful and are logged into the web interface,
    please show your appreciation and click on the star below... Thanks!


  4. #4
    Join Date
    Jun 2008
    Location
    Netherlands
    Posts
    29,784

    Default Re: Python scripts fail on 12.3

    And please, next time you post computer text here in a post, use CODE tags around it (I see you tried some non-standard font to make things more clear, but the CODE tags are much better). You get the CODE tags by clicking on the # buttton in the toolbar of the post editor.
    Henk van Velden

  5. #5
    Join Date
    Feb 2009
    Location
    Oxford, UK
    Posts
    12

    Default Re: Python scripts fail on 12.3

    Quote Originally Posted by flymail View Post
    On 2014-01-28, jhd10374 <jhd10374@no-mx.forums.opensuse.org> wrote:
    >

    Have you tried adding the directory containing xmlcommon.py to your python path inside ~/.bashrc? e.g.

    Code:
    export PYTHONPATH=.:/home/user/path_to_xmlcommon/:PYTHONPATH

    Not specifically in .bashrc, but I have the following in /etc/profile.d/python.sh:

    Code:
    export PYTHONPATH=/srv/www/cgi-bin
    Since the code is run as a cgi script by Apache, I wasn't convinced putting it in a user's .bashrc would be useful. However, I'll give it a whirl.

    Cheers,
    James





  6. #6
    Join Date
    Feb 2009
    Location
    Oxford, UK
    Posts
    12

    Default Re: Python scripts fail on 12.3

    Quote Originally Posted by malcolmlewis View Post
    Hi
    So the beginning of the script calls all the imports os sys etc?

    You might have to add some debug to the scripts so it tells you where
    it's looking when it trys to import the module.

    --
    Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
    openSUSE 13.1 (Bottle) (x86_64) GNOME 3.10.2 Kernel 3.11.6-4-desktop
    If you find this post helpful and are logged into the web interface,
    please show your appreciation and click on the star below... Thanks!

    Yes: the script starts:

    Code:
    #!/usr/bin/python
    
    
    from subprocess import Popen
    from xml.dom import minidom
    import cgi     
    import cStringIO
    import os
    import pycurl  
    import re
    import socket
    import logging
    import urllib
    import urllib2
    from urlparse import parse_qs, urlsplit, urlunsplit
    from urllib import urlencode
    import hashlib
    import sys
    import datetime
    
    
    
    
    # Custom modules - these must be placed in the same directory as this file
    
    
    import xmlcommon
    import hspotcommon
    J

  7. #7

    Default Re: Python scripts fail on 12.3

    jhd10374 wrote:
    > flymail;2620096 Wrote:
    >> On 2014-01-28, jhd10374 <jhd10374@no-mx.forums.opensuse.org> wrote:
    >> Have you tried adding the directory containing xmlcommon.py to your
    >> python path inside ~/.bashrc? e.g.
    >>

    > Code:
    > --------------------
    > > >

    > > export PYTHONPATH=.:/home/user/path_to_xmlcommon/YTHONPATH
    > >

    > --------------------
    >>

    >
    > Not specifically in .bashrc, but I have the following in
    > /etc/profile.d/python.sh:
    >
    >
    > Code:
    > --------------------
    >
    > export PYTHONPATH=/srv/www/cgi-bin
    >
    > --------------------


    I'm noeither a python guru nor a shell expert, but AFAIK profile is only
    used for login shells whilst bashrc is used for all. Since a CGI script
    is not a login environment, the path needs to be set in bashrc, or
    explicitly in the script. Normally it isn't usual to include the current
    directory (.) in system paths, because it increases the security risk.

  8. #8
    Join Date
    Feb 2009
    Location
    Oxford, UK
    Posts
    12

    Default Re: Python scripts fail on 12.3

    Quote Originally Posted by djh-novell View Post
    jhd10374 wrote:
    > flymail;2620096 Wrote:
    >> On 2014-01-28, jhd10374 <jhd10374@no-mx.forums.opensuse.org> wrote:
    >> Have you tried adding the directory containing xmlcommon.py to your
    >> python path inside ~/.bashrc? e.g.
    >>

    > Code:
    > --------------------
    > > >

    > > export PYTHONPATH=.:/home/user/path_to_xmlcommon/YTHONPATH
    > >

    > --------------------
    >>

    >
    > Not specifically in .bashrc, but I have the following in
    > /etc/profile.d/python.sh:
    >
    >
    > Code:
    > --------------------
    >
    > export PYTHONPATH=/srv/www/cgi-bin
    >
    > --------------------


    I'm noeither a python guru nor a shell expert, but AFAIK profile is only
    used for login shells whilst bashrc is used for all. Since a CGI script
    is not a login environment, the path needs to be set in bashrc, or
    explicitly in the script. Normally it isn't usual to include the current
    directory (.) in system paths, because it increases the security risk.

    Ok, that makes sense. Since a ~/.bashrc is an individual user's additions to bashrc, I assume I am looking to set this somewhere in the /etc directory?

    Aha - In there I can see only /etc/bash.bashrc which warns me against making changes to it and to use bash.bashrc.local

    Testing....

    Cheers,
    James

  9. #9
    Join Date
    Jun 2008
    Location
    Netherlands
    Posts
    29,784

    Default Re: Python scripts fail on 12.3

    When I understand the explanation above correctly then an Apache process, which is normaly owned by user wwwrun, starts the CGI program, which in this case is a python script, and that will thus also run with owner wwwrun.

    When this assumption is correct, it is useless to add anything to .bashrc of another user than wwwrun. Also, no bash is involved at all, thus changing e.g. /etc/bash.bashrc.local is also useless.

    The above because I get the idea that seraching goes along a path that is not very promising. Just my two cents.
    Henk van Velden

  10. #10

    Default Re: Python scripts fail on 12.3

    hcvv wrote:
    > When I understand the explanation above correctly then an Apache
    > process, which is normaly owned by user wwwrun, starts the CGI program,
    > which in this case is a python script, and that will thus also run with
    > owner wwwrun.
    >
    > When this assumption is correct, it is useless to add anything to
    > .bashrc of another user than wwwrun. Also, no bash is involved at all,
    > thus changing e.g. /etc/bash.bashrc.local is also useless.


    Very true! So either change the library path in the code itself or make
    use of Apache's SetEnv directive

Page 1 of 3 123 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •