Want to develop a web interface to remotely schedule recordings on the OSD ?
Or maybe turn it into a music server that can be controlled from your PDA or cellphone browser ?
These and other similar web-based ideas were proposed in the mailing list or in chat, but what was missing was a web server that was light enough to run on the OSD, and still capable of running scripts to dynamically generate web pages. So I took a small break from Project Lobster and investigated some possible solutions.
In the end I settled for the Xavante web server plus CGIlua (also known as Kepler framework). Think Apache plus PHP, but without the bloat.
I got this combo running on the OSD and it seems to work fine and have a good feature set. Check the README for instructions and more details.
At the moment this is mostly developer-only material, in the sense that it still needs you to have your OSD file system mounted over NFS.
But aside of that, you don't need to compile anything if you don't want to. Just copy some files and you will be ready to roll.
I hope that sooner or later this and the lua interpreter itself will be included into the main OSD distribution, so that even people with stock firmwares will be able to use it.
For comments, questions and any other feedback please contact me in #neuros or nerochiaro a gmail d com
Comments
Yet another language?
I just ported mini_httpd for a webserver. This and its variants are very common in these small, single board computers because porting it is a non-task (< 5 minutes). CGI support is conventional.
I'm a bit put off by Lua because its "yet another language". Developing web applications for these sorts of boards is already bad enough -- you're bouncing between three or four different techniques, trying to keep it all together (I'm speaking from experience, BTW). Lua just adds yet another thing to the mix (and since most CGI programming seems to be ways to simplify parameter parsing and database access, neither which are likely to be a big deal in this unit, we may be adding complexity where its not needed). Incidentally, small footprint, highly extensible semi-interpreted languages have been around for decades. The granddaddy of them all -- Forth -- dates from the 70s. (There's a refined, embeddable, variant called Ficl which is free for the downloading -- I've used it extensively since you can get it up on any old bit of hardware, OS or no OS, in two hours or less. I've also never even started to really exploit its capabilities.)
The real challenge will be finding a web browser for the OSD. This would open up the OSD to Internet audio and video sources. There's a lot more material on the 'net than my cable system these days, and I don't just mean ripped/pirated movies (I'm not interested in that stuff anyway). A browser / server combination also makes a useful local interface instead of a monolithic piece of software. I've started looking at "Dillo" for a browser, I think this will integrate with the existing graphical environment. (Thinks, though -- inputting URLs like texting using the remote's numeric keypad -- not an encouraging thought!)
Yes
Let's suppose i picked Ficl, Lisp or any another language that "has been around for decades" and that can also be used to write CGIs. Then someone else would've raised the very same objection you raised. The only "solution" would be writing CGIs in C, so there's no other language involved, but i would consider that far from ideal.
Also there are plans for using lua to do other things inside the OSD, so it was "already there" in a sense.
Lua just happens to be the one that among the alternatives that were considered appears to be the most suitable (not just by me, there was discussion in the IRC channel for a while and various alternatives were tried and discarded (php and python among them)).
One thing that is not set in stone, instead, is the web server. I just picked xavante because lighttpd was broken in regard to the usage with the cgilua platform. If there are better alternative, there is still time to consider them.
The mailing list or the IRC channel are better places to discuss all of this, however. Please join us there.
(I won't comment on the web browser since i've not looked into that area yet.)
Xavante and CGILua
Nice to know that Xavante and CGILua have been considered for OSD!
May I ask what versions of them were you using? We have updated both of them recently and that may solve some of the reported issues.
The Kepler team is currently targeting devices such as the Nokia 770 and the NSLU2 (aka Slug), so OSD would be very well tuned with our development roadmap. Just let us know how we can help you guys. :o)
Xavante and CGILua
There's now an answer to your questions in the <a href="http://lists.luaforge.net/pipermail/kepler-project/2006-October/000260.html" title="reference on Kepler project mailing list" target="_blank">Kepler project mailing list</a>.
Thanks for the interest!
Security
The inherent problem with cgilua is that you can do ANYTHING - just while making apps, i've frozen xavante many times by accidently having never-ending loops; also, if someone got a page on there, they could do serious damage - full permissions to the system, can run any function, can write programs to disk - TOTALLY insecure.
Precautions will need to be taken. - though, AFAICS, the OSD has enough security risks as is.
Security
That's the inherent security problem with ANY cgi / web framework that doesn't run in a limited sandbox.
Either you limit what the programmer can do (not too hard, just export into the script environment a limited/protected version of the libraries) or you leave the programmer a gun in his hand and the ability to shoot his own feet.
I much prefer the second solution. The programmer should always know what he's doing in the first place. If he freezes the system in a loop or wipes the disk, that's his mistake and should pay the consequences.
As for "if someone gets a page up on there" ... if an hacker can get an arbitrary page on the OSD, he might as well upload a program there and run it. It's a security problem in general, not specific to the web environment.
Much Awesome!
Thanks Nero, what about security? Is there any reason we shouldn't put this on the "stock distribution?"
Security
It has the same security issues as the whole OSD.
That is, no one cared about security so far, since the OSD was (and probably still is) supposed to live inside your local network.
Aside of that, i don't have any data on how secure this setup would be, but it seems that the web page scripts are run in a fully isolated environment. So if the web page script itself doesn't do anything stupid, we should be quite safe (bugs aside, of course).
Also we can put this in, but with the need to enable it from the main app (or some other way). So in the out of the box setup it won't create any security issue.
Post new comment