Blinkt python library not working if apache is running the script


#1

I’m using my pi as a tiny personal web server, and writing everything in python. I’m not using any frameworks, so apache is running the scripts through cgi. I thought it would be neat to have the scripts do some stuff with the Blinkt I’ve got that until now has been sitting there doing nothing (for example, I’d like a light to come on at the start of a script then turn off at the end of the script, to give me a visual indicator that a script is being executed).

Blinkt works perfectly if I run scripts that use it as a user, but (for security reasons) apache runs python scripts as a weird “not a real user” user, and when that happens the Blinkt library doesn’t work.

The error message it spits out is

<type 'exceptions.RuntimeError'>: No access to /dev/mem. Try running as root!

and originates here

 /usr/lib/python2.7/dist-packages/blinkt.py in show()
     65         GPIO.setmode(GPIO.BCM)
     66         GPIO.setwarnings(False)
=>   67         GPIO.setup([DAT,CLK],GPIO.OUT)
     68         _gpio_setup = True

Is there anything I can do to make this work? (Besides some kind of horrible hack that makes apache run scripts as root - which ain’t gonna happen on my watch!).


#2

Like you said, Apache is running the script under the user context wwwdata:wwwdata which indeed does not have any access to /dev/mem.

There are so many ways to work around this, but in my humble opinion you’re best off using Flask or a similar Python HTTP server to supply an interface directly.

Apache is maximum overkill when it comes to stuff like this- and since your scripts probably aren’t solving any of the problems that might arise from multiple simultaneous accesses anyway, there’s no need for anything but a simple, single-threaded, Flask app.

See: http://flask.pocoo.org/


#3

Thanks for the quick response. I’m not using a framework and don’t intend to any time soon - restructuring an entire (reasonably large and complex) project to fit a new paradigm just to get some LEDs working is also maximum overkill. I was hoping there was a quick and easy solution.


#4

You could grant the wwwdata user access to the gpio group, but if it’s running under the user wwwdata and the group wwwdata this doesn’t help much.

Another hack I’ve used before is to create a udev rule to give a device more permissive permissions, but that was for i2c and not general gpio.