Nut upsuser - Dec 2009 - My previous post (lengthy, lots of tarace output)

Ping?

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)

What does "it" mean in the sentence "What time is it?"?

Citeren Gene Heskett <gene.heskett op gmail.com>:
> Ping?
I didn't comment to that message (for exactly the reasons in the  
subject field) and you seemed to be in the process of figuring stuff  
out yourself (which we prefer, since then people actually learn,  
instead of us developers telling them how to do things). But  
apparently you've hit a brick wall in the process.

Please post the present status of the

1) usbhid-ups (driver)
2) if 1) is running, the upsd (server)
3) if 2) is running, the upsmon (client)

They all need to be up and running in this order. It's a waste of  
effort to try to run the upsd server, if the driver isn't running  
properly. So the first you need to do is make sure you have a running  
driver.

The line

     /path/to/usbhid-ups -DDD -a yourups

should result in a continuous flow of information. Dump the output of  
the first 60 seconds in a logfile, gzip it and attach the result to a  
message.

It might also help to upgrade to a more recent version of NUT (2.4.1),  
since the version you're running now (2.2.2) seems to be quite outdated.

Best regards, Arjen

PS  Don't post strace output, since unless you know exactly what  
you're looking for, it will just wastes bandwidth. The right amount of  
-D options is easier on our eyes.
-- 
Please keep list traffic on the list

On Saturday 02 January 2010, Jesper Klit Jensen wrote:
>Hi,
>
>Here are what I have done (I may be special):
>I created a directory in my /srv/www/nut/ where I moved all the web nut
>stuff into
>I created the nut.conf in /etc/apache2/conf.d
Here that is /etc/httpd/conf.d
>Content of the nut.conf
><<BEGIN>>
>ScriptAlias /nut/cgi-bin /srv/www/nut/cgi-bin
>
><Directory /srv/www/nut/cgi-bin>
>    SSLRequireSSL
>    Options ExecCGI
>    AllowOverride None
>    Order deny,allow
>    Deny from all
>    Allow from 127.0.0.1
>    allow from 10.240.120.0/24
>    allow from 10.240.140.0/24
>    allow from 10.240.150.0/24
>    allow from 10.240.160.0/24
></Directory>
>
>Alias /nut /srv/www/nut/htdocs
>
><Directory /srv/www/nut/htdocs>
>    SSLRequireSSL
>    Options ExecCGI
>    AllowOverride None
>    Options None
>    order deny,allow
>    deny from all
>    allow from 127.0.0.1
>    allow from 10.240.120.0/24
>    allow from 10.240.140.0/24
>    allow from 10.240.150.0/24
>    allow from 10.240.160.0/24
></Directory>
><<END>>
And httpd didn't like the <<BEGIN>>,<<END>> labels
tossing error exits at me
till they were commented out.  And obviously I changed the addresses to my 
local network, all behind an x86 based dd-wrt firewall.
>Files in /srv/www/nut/
>./cgi-bin/upsset.cgi
>./cgi-bin/upsimage.cgi
>./cgi-bin/upsstats.cgi
>./cgi-bin/.htaccess
>./htdocs/header.html
>./htdocs/bottom.html
>./htdocs/index.html
>./htdocs/nut-banner.png
>
>Hope that this helps. You can just remove the SSL part. I is just me......
A little paranoia is a good thing. ;-)
>Good luck
>
>Jesper
>
>On 1/1/2010 23:22, Gene Heskett wrote:
>> On Friday 01 January 2010, Jesper Klit Jensen wrote:
>>> Hi
>>>
>>> Regarding the web part the challenge is on your web server. You
need to
>>> enable the exec-cgi for the location of the cgi scripts.
>>
>> And where the heck is that?  FF-3.5.8  IIRC.  I just rescanned both the
[...]

I have set up a /var/www/nut tree as described above, still with the SSL, but 
if I include the <<BEGIN>>, <<END>> constructions in  
/etc/httpd/conf.d/nut.conf, restarting httpd (apache) barfs.  Complains they 
are unterminated.  Is this a fedora-ism?, it (httpd) is happy if those two 
lines are commented out. 

In FF, open a file at file:///var/www/nut/cgi-bin/upsstats-single.html
and I get the dataless display I showed before, but the SSL locked icon
isn't
there either.

Am I opening the wrong file?

And a new problem stuck up its hand, palm forward when I rebooted.  Now one 
of the hald-addon daemons has an air tight lock on /dev/hiddev0 and the 
driver can't start, no permissions.

And because the system only reports the 1st 15 chars of the process's name, 
and lsof barfs if you ask for more,  I have no idea which of the 
/usr/sbin/hald-addon* pieces to nuke.  And if I kill its process number, 
usbhid-ups still can't start.  Getting a long trace ending in:

Device matches
failed to claim USB device: could not claim interface 0: Operation not 
permitted
failed to detach kernel driver from USB device: could not detach kernel 
driver from interface 0: Operation not permitted
failed to claim USB device: could not claim interface 0: Operation not 
permitted
failed to detach kernel driver from USB device: could not detach kernel 
driver from interface 0: Operation not permitted
failed to claim USB device: could not claim interface 0: Operation not 
permitted
failed to detach kernel driver from USB device: could not detach kernel 
driver from interface 0: Operation not permitted
failed to claim USB device: could not claim interface 0: Operation not 
permitted
failed to detach kernel driver from USB device: could not detach kernel 
driver from interface 0: Operation not permitted
Can't claim USB device [050d:0751]: could not detach kernel driver from 
interface 0: Operation not permitted

[root at coyote conf.d]# ls -l /dev/hiddev0
crw-rw-r-- 1 root nut 180, 0 2010-01-03 22:01 /dev/hiddev0

Ideas?  Or something you've not encountered?

Thank you very much for your assistance, Jesper.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)

You love peace.