Sorry that this is a bit off-topic, but I don't know where else to turn.
I've been trying to setup a server to run the GPL OpenQM (2.6-6) under
Ubuntu server 8.04. Previously, I had one running 6.10 fine, and I
had a copy of my install notes, so I setup the 8.04 Server in the same
way. Or as close as possible considering the newer Ubuntu is
obviously sightly different. OpenQM itself runs fine on both servers
from console session.
Anyway, I use a little CGI script to access QM from a web browser.
It's been working fine under 6.10, but don't want to play ball with
8.04.
Here it is:-
#!/bin/bash
cd /home/anji
qm -quiet "BGATEWAY" < /dev/stdin
Everything runs absolutely fine, and I can extract the POST data using
QM Basic INPUT statements.
However under 8.04, I get this message in the /var/log/apache2/error.log:-
[Wed Apr 30 18:10:23 2008] [error] [client 192.168.1.120] Premature
end of script headers: bgateway2.cgi
/usr/lib/cgi-bin/bgateway2.cgi: line 11: /dev/stdin: No such device or address
Now this just don't make sense to me. /dev/stdin is a dull, boring,
standard as things come. It's there allright.
I've tried changing bash to sh - no joy. I've checking that
/dev/stdin does exist - no joy. In fact lots of things. I'm now
getting desperate, and the server might have to go to the skip
(dumpster) if I don't solve it soon!
Any, and all suggestions are very welcome. I expect I'm doing
something very bone-headed. Laugh at me all you like, as long as you
give me a clue!
--
Ashley Chapman
Check permissions on /dev/stdin. You can also re-structure your
redirect as:
cat - | qm -quiet "BGATEWAY"
This is identical to yours, it just access the handle directly instead
of using the device.
In theory, you should not need to redirect at all with a simple:
qm -quiet "BGATEWAY"
and stdin should just work.
If you still need to punt try:
cat - > /tmp/$$.tmp
qm -quiet "BGATEWAY" $$.tmp
rm $$.tmp
and read from the temp file instead of stdin.
Doug Dumitru
EasyCo LLC
2008/4/30 Doug Dumitru <do...@easyco.com>:
>
> Ashley Chapman wrote:
> > Help! Help!
> >
> > Sorry that this is a bit off-topic, but I don't know where else to turn.
> >
> > I've been trying to setup a server to run the GPL OpenQM (2.6-6) under
> > Ubuntu server 8.04. Previously, I had one running 6.10 fine, and I
> > had a copy of my install notes, so I setup the 8.04 Server in the same
> > way. Or as close as possible considering the newer Ubuntu is
> > obviously sightly different. OpenQM itself runs fine on both servers
> > from console session.
> >
> > Anyway, I use a little CGI script to access QM from a web browser.
> > It's been working fine under 6.10, but don't want to play ball with
> > 8.04.
> >
> > Here it is:-
> >
> > #!/bin/bash
> > cd /home/anji
> > qm -quiet "BGATEWAY" < /dev/stdin
> >
> > Everything runs absolutely fine, and I can extract the POST data using
> > QM Basic INPUT statements.
> >
> > However under 8.04, I get this message in the /var/log/apache2/error.log:-
> >
> > [Wed Apr 30 18:10:23 2008] [error] [client 192.168.1.120] Premature
> > end of script headers: bgateway2.cgi
> > /usr/lib/cgi-bin/bgateway2.cgi: line 11: /dev/stdin: No such device or address
>
> Check permissions on /dev/stdin.
permisions are 777 on both old and new server. /dev/stdin actually
points to /proc/self/fd/0. this then points to /dev/pts/0 on the old
server, and /dev/pts/1 on the new one. Both have same permissions.
But I've noticed that the /proc filesystem is mounted differently
between the two versions.
Old ==> proc on /proc type proc (rw)
New ==> proc on /proc type proc (rw,noexec,nosuid,nodev)
You can also re-structure your
> redirect as:
>
> cat - | qm -quiet "BGATEWAY"
Good idea. But still no joy :-(
>
> This is identical to yours, it just access the handle directly instead
> of using the device.
>
> In theory, you should not need to redirect at all with a simple:
>
> qm -quiet "BGATEWAY"
>
> and stdin should just work.
Yes, in theory. But in practice I found I needed the stdin redirect.
It's been working well for 6 months on the old server. millions of
requests.
>
> If you still need to punt try:
>
> cat - > /tmp/$$.tmp
> qm -quiet "BGATEWAY" $$.tmp
> rm $$.tmp
>
> and read from the temp file instead of stdin.
>
>
> Doug Dumitru
> EasyCo LLC
>
>
>
>
> >
> > Now this just don't make sense to me. /dev/stdin is a dull, boring,
> > standard as things come. It's there allright.
> >
> > I've tried changing bash to sh - no joy. I've checking that
> > /dev/stdin does exist - no joy. In fact lots of things. I'm now
> > getting desperate, and the server might have to go to the skip
> > (dumpster) if I don't solve it soon!
> >
> > Any, and all suggestions are very welcome. I expect I'm doing
> > something very bone-headed. Laugh at me all you like, as long as you
> > give me a clue!
> >
> >
>
>
> >
>
I'm going for a little sleep, and will try again in the morning.
Looks like I'm going to have to investigate the /proc mount options.
And the 0 or 1 target for the links. Possible that it's there.
Thanks again.
--
Ashley Chapman
The /dev/pts/0 vs /dev/pts/1 just means you are the first ssh on one
server and the second on another. This follows the user around.
Not sure if the 'nodev' is it or not.
Remember that apache is running without a "terminal", so it can be hard
to emulate it at the console.
Doug Dumitru
Ahh, I thought it might mean file 0 (stdin) and file 1 (stdout) were
getting mixed up.
>
> Not sure if the 'nodev' is it or not.
At the moment, it looks like something I install upsets the
permissions on my proc filesystem. Obviously I can't just change
them, as they are dynamic. got a feeling it's the install of the
xinetd.
I'm just about to reload the server from scratch again, and check
every step to see when the perms go off.
>
> Remember that apache is running without a "terminal", so it can be hard
> to emulate it at the console.
>
Haha, you don't say! :-) It's a devil.
> Doug Dumitru
Thanks again. Your tips are much appreciated. My peers just take the
opportunity to laugh at me, and tell me how simple things are with
windows. - Well it's not often that they get the chance.
--
Ashley Chapman
I've finally got to the bottom of the problem. Here's the details in
case anybody comes across the problem in the future:-
OpenQM, can run in a pipe mode, where stdin is fed through to any
INPUT or KEYIN() statements. When in pipe mode, the EOF condition is
handled, whilst ordinarily, QM would simply terminate on a EOF.
In order to trigger this mode, qm has to be called in a script like this:-
qm -quiet "BGATEWAY" < /dev/stdin
Which works fine until changes in the linux /dev dynamic filesystem
interfered with /dev/stdin. Apparently, these changes occurred a
couple of years back, and I didn't see them as the server I use for my
QM experimenting runs an old version of Ubuntu.
Instead, OpenQM can be called in the script like this:-
cat - | qm -quiet "BGATEWAY"
This method seems to work at all times. I've stress-tested it, and it
appears robust, even with large amounts of post-data.
At this point, I confess to Doug, that his earlier suggestion does
indeed work, and it was just my testing that was faulty. :-)
I had neglected to clear out a cache, so the new code did not run. Oops.
--
Ashley Chapman