Getting SNMP to access the BMP180 pressure sensor.... running a script as root?

It should run as snmp.
SHOULD.
Test this by using
su - snmp
and then running the script.
If it moans about no password for user snmp you can create one with
sudo passwd snmp
Essentially you want to login as snmp user and test everything.
root can do anything, which is as good a reason as any to *not* use root permissions - and making a su-able script is not so easy.
What you should do is ensure that user snmp is the user in play and that the script will work with that user.
That is the accepted clean way to do things.
Daemons run with either root or user permissions - snmpd is apparently running with snmp user permissions. Be aware that it may not be running with the same *environment* set, as user snmp would. I.e it is common and good practice to not aussume that PATH is set , and so any scripts that invoke binaries should do so explicitly quoting the whole path as in e.g. /usr/bin/echo etc. etc. or set PATH within the script.
--
Everything you read in newspapers is absolutely true, except for the  
rare story of which you happen to have first-hand knowledge. ? Erwin Knoll
Reply to
The Natural Philosopher
Loading thread data ...
No, that wouldn't help; root already owns the device. Try adding 'pi' (if that's how you're logged in) to the i2c group.
Reply to
Tony van der Hoff
[]
OK, I think I've narrowed things down a little, and I don't think that the i2c group is quite as relevant, or something else is happening. I've just set up another BMP180 sensor on a different RPi, and not fiddled with device permissions. I run a simple program, pressure.py:
#!/usr/bin/python import Adafruit_BMP.BMP085 as BMP085 sensor = BMP085.BMP085(mode=BMP085.BMP085_ULTRAHIGHRES) pressure = sensor.read_pressure() + 2175 print '{0:0.0f}'.format(pressure)
with the following results:
pi@raspi-5 ~/Adafruit_Python_BMP/examples $ python pressure.py Traceback (most recent call last): File "pressure.py", line 3, in sensor = BMP085.BMP085(mode=BMP085.BMP085_ULTRAHIGHRES) File "build/bdist.linux-armv6l/egg/Adafruit_BMP/BMP085.py", line 66, in __init__ File "build/bdist.linux-armv6l/egg/Adafruit_GPIO/I2C.py", line 66, in get_i2c_device File "build/bdist.linux-armv6l/egg/Adafruit_GPIO/I2C.py", line 95, in __init__ IOError: [Errno 13] Permission denied pi@raspi-5 ~/Adafruit_Python_BMP/examples $ sudo python pressure.py 100659
Adding the user pi to the group i2c makes no difference at all - still the same error. Running with sudo it works, and I believe that with the i2c device having o:rw permission it would work as well.
Does this suggest that the groups idea isn't relevant, or that I/we are tackling the groups in an incorrect way? I'm puzzled!
--
Thanks, 
David 
 Click to see the full signature
Reply to
David Taylor
OK so user pi doesn't have permission and root does.
Did you log out and log back in? Try it after that.
If you didn't log out/in then all bets are off.
As for running it at boot, which user runs your script? Are you sure it's root? Is it nobody? Why don't you change the i2c script that fails and output the user id. Then you would know which user needs to be in the i2c group to run it at boot up.
Reply to
mm0fmf
Yes, of course it works with root permissions. root owns the device, and has rw permissions.
Did you reboot (or at least log out) after adding pi to the group? That's required. To check to which groups your user belongs type groups : tony@rpi1:~$ groups tony tony : tony adm sudo gpio i2c
You can tick off what you've found:
2. You've identified that it's the i2c device that's denying access, by setting its global permissions. 3. From your ls -l, the i2c device has its group permissions rw, as required. 4. Its group is 'i2c'.
Therefore, to access the i2c device the user MUST be either root, or be a member of i2c.
The group is totally relevant. You need to find out which user is trying to access the i2c device. We can't do that for you.
Reply to
Tony van der Hoff
[]
[replying to Tony as well]
No, I did not appreciate that a logout and in was required, so I had not done so. Now it works, so we are getting somewhere. I will try and determine the user ID. Running that as if it were an actual SNMP retrieved value gave:
pi@raspi-5 ~ $ /usr/bin/snmpget -v 2c localhost -c public .1.3.6.1.2.1.25.1.20 iso.3.6.1.2.1.25.1.20 = STRING: "uid=107(snmp) gid=110(snmp) groups=110(snmp)" pi@raspi-5 ~ $
so it looks as if the script is being run as user "snmp", just as you might expect. I've now added snmp to the i2c group, and rebooted. Still getting a "0" value back from the snmpget, though.
Is snmp allowed to run Python? Checked and it is (replaced all the sensor stuff with a "pressure = 123456"). So it's something about trying either to create (i.e. open) or read the sensor device.
Still puzzled, but very appreciative of your help. I'm learning a lot!
--
73, 
David 
 Click to see the full signature
Reply to
David Taylor
Things run from start up scripts have a very different environment to when run from the shell prompt and especially likely to cause issues is the fact that $PATH will different.
Reply to
mm0fmf
[]
Yes, I can appreciate. This isn't a startup script, but a script run by snmpd in response to a request, but I guess the principle of a strange environment may be the same.
I did try adding "pi" to the ic2 group and, as predicted, the requirement to run the simple program with sudo was dropped and it ran just with "python ".
snmp is also in the i2c group, but that alone isn't enough.
Unsure how to proceed from here....
--
Cheers, 
David 
 Click to see the full signature
Reply to
David Taylor
Adding the relevant user to the i2c group is the clean way.
The device is recreated with consistent ownership and permissions at each boot, there are ways and means you could alter those permissions each time, or you can make the account that snmpd runs under a member of the i2c group which has permissions and will keep them between reboots.
I've not followed all the ins and outs, have you still got problems adding the snmp user to the i2c group?
Reply to
Andy Burns
given the bash script is being run, the O/P could add a
whoami > /tmp/somefile
command to find out
Reply to
Andy Burns
Why the '> /tmp/somefile' part?
Reply to
Rob
[]
Yes.
If I add the user pi to the i2c group, I can run the example program with out without sudo. Without adding pi to the group, sudo is require to run that example.
If I add the user snmp to the i2c group, the program when run by snmpd still fails.
--
Cheers, 
David 
 Click to see the full signature
Reply to
David Taylor
I checked that, and the user is snmp. I made the script echo a string instead of running the program, and got:
uid=107(snmp) gid=110(snmp) groups=110(snmp)
--
Cheers, 
David 
 Click to see the full signature
Reply to
David Taylor
so add snmp to the i2c group
--
"Consequences, Schmonsequences, as long as I'm rich." 
-- Looney Tunes, Ali Baba Bunny (1957, Chuck Jones)
Reply to
alister
....
You could temporarily load up the script with display commands. Echoing $PATH or (better) running env will show you most of the useful environmental stuff. If you can't see anything the script displays, you can send the output to a file "env >/tmp/smtp_environment.txt".

--
martin@   | Martin Gregorie 
gregorie. | Essex, UK 
 Click to see the full signature
Reply to
Martin Gregorie
And/or "whoami > /tmp/user.txt", or was the user already clear? Sorry haven't kept up on the whole thread.
Reply to
A. Dumas
... and reboot! Or at least log off/on.
Reply to
A. Dumas
I did. It made no difference.
--
Cheers, 
David 
 Click to see the full signature
Reply to
David Taylor
Because it's running being run indirectly by snmp ...
Reply to
Andy Burns
But what point is there in sending the output to a file? I don't understand.
I could see a use for the whoami command (better alternatives exist), but it would be in something like:
if [ "`whoami`" != "root" ] then ... do something only required when not root ... fi
Reply to
Rob

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.