fractalnavel

so, y'know, i haven't done taxes, or even summarized cash flow from last year, and it's like one in the morning, so of course, being supremely rational, i decide it's time to install an http server on the olpc xo ^[1].

^[2]

your mission

not just any server; i go for the micro_httpd.  i first saw this years ago when my router coughed up 404s; apparently this is what they use on its embedded system (along with other stuff, because it apparently supports asp pages as well).  and i had been familiar with acme labs from long before that.  one of those grandaddy-of-the-web sites.

sure, a lot of other options are more reasonable in terms of feature & configuration flexibility, but this one was appealing for several other reasons:

• at under 200 lines of c, it can be torn apart like an old watch
• i had already downloaded it through the xo's "browse" activity - so where does it put the files ?
• binaries are not distributed, it has to be "made" locally (or is the proper past tense there "maked" ?  or "'make'd" ?)

and i only really want an absolute minimum of features anyway.

part of the way this thing achieves its micro-ness is by offloading the network comms to inetd - or, in the xo's case, xinetd.  more on that later.

button, button, who's got the ...

first step: where the hell is that damn thing that i downloaded anyway ?  oh yeah - back to that mess of a datastore that the xo uses ^[3].  managed in the guise of its journal, all downloaded files (and many other things) are not stored under their original names, the names have been changed to protect the innocent hashes.  thankfully, they still maintain their original type information (i could see this in thunar, but not through ftp).  digging back into the journal, i could see the date of the download, so it wasn't too difficult to determine which file was which (/home/olpc/.sugar/default/datastore/store/2ced633e-7f17-4233-8ad5-a5642e6f), but this is still silly.

anyway, copied it to a working directory & changed its name to the original, and started from there.

oh, sure, using wget would make more sense, given these circumstances.  i'm just following along a la "tao of xo".

go ahead, make my day app

so the instructions say "just do a make".  right.  well, this is an xo, there ain't no such thing.  luckily, unlike the removal of cifs (module?), this is still available as an installable package.  so - "yum install make".

what about a compiler ?  as is well documented everywhere, all linux distros come with gcc.  nope, not the xo.  so - "yum install gcc".  which comes with a couple extra mb in dependencies, for a total of 8mb.

finally, "make [install]".

yeah, ok, that was straightforward.  sure.  but well, i will be needing those tools anyway, eventually.  one of the reasons for doing http this way, remember ?

con-fig-u-ra-a-tion

more instructions:

To install it, add a line like this to /etc/inetd.conf:


    micro_http  stream tcp nowait nobody  /usr/local/sbin/micro_httpd micro_httpd dir


Make sure the path to the executable is correct, and change "dir" to be
the directory you want to serve.
Then add a line like this to /etc/services:


    micro_http   port/tcp   #Micro HTTP server

inetd, eh ?  nope - again, the xo has no such thing.  something so basic to unix / linux.  then again, i can see why.  it has the potential to open up all kinds of security issues, and certainly these machines are not intended to provide network services.  and in any case, xo's base os ^[4] is an adaptation of fedora, which uses xinetd.  nope, that's not on the xo either.  here we go again - "yum install xinetd".  i think i've added more than 10mb so far.

of course, xinetd's settings are handled differently than inetd.  mostly it's a straightforward translation though.  here is the xinetd.conf version (only the relevant bits; well, ok, and some others): 

defaults
{
    log_type    = SYSLOG daemon info 
    log_on_failure  = HOST
    log_on_success  = PID HOST DURATION EXIT
    cps         = 50 10
    instances   = 50
    per_source  = 10
    v6only      = no
    groups      = yes
    umask       = 002
}

service http
{
    disable     = no
    id          = http
    wait        = no
    socket_type = stream
    protocol    = tcp
    user        = olpc
    server      = /usr/local/sbin/micro_httpd
    server_args = /
    port        = 80
    only_from   = 127.0.0.1 10.11.128.0/24
}

this is actually divided between /etc/xinetd.conf (defaults) and /etc/xinetd.d/microhttp-server; xinetd.conf has "includedir /etc/xinetd.d" as the last line.  and those are really "defaults", that section is unchanged from the xinetd install.

note that i've exposed the entire system to browsing; at least, the parts that the olpc user can see.  and i've contrained access to my lan (and the xo itself).  assuming i don't hook up with some dhcp somewhere with the same segment configured, i should be ok.

see me, run mee-ee-ee ...

finally, i can test all this out.  turns out the xinetd installation already handled the chkconfig stuff for me (runlevels 345), so "/etc/inet.d/xinetd restart", and voila.  well, not really; i had some issues differentiating between underscores and hyphens in filenames, but once i got that dyslexia straightened out, http popped right up ("fuser -vn tcp 80" is one way of checking).

what does this let me do ?  just a simple way to browse the filesystem, mainly.  but it was also a learning experience.

time of completion: 7am ?  it was light out, anyway.

observation: really, how "micro" was all that ?

i'm thinking i may want to change some of that source code to give me something other than the classic acme labs green as a directory listing page background color default, but y'know, it has its, uh, "charms".

finis

so now i have acquired a few more tools one usually finds in linux, at the cost of more used space.  being such a newb at this, i still have to chase down log file usages and make sure these things are being properly limited and / or rotated.  certainly don't want to suck up disk space like that.  plus i need to figure out how to clean up xo's journal (i remember seeing stuff on that somewhere).  also, is there a log of everything i've "yum"ed ?

yet again, i'm struck by how obtuse this whole linux thing is.  in some cases, elegantly obtuse, where "they" have gone out of their way to automate really boneheaded stuff (assuming one knows the proper magic incantations), instead of shifting paradigms.  well, that shift is happening anyway. 

another recent musing has been that the linux community creates a huge amount of churn.  no way that will ever be able to keep up with more focused efforts from players like microsoft, etc.  and in fact, whenever something threatening does pop up out of the open source world, the big guys just scarf the concepts up and move on. 

and that part is good.  the backyard mechanics can play as much as they want, and every now and then a Good Idea^TM gets cranked out.  then the big machines take it from there.  no little guys, and we'd have the same old shit.  but the little guy needs to get a grip: although he is the source of some innovation and it's good to have gadflies, it is not the same thing as being a player himself.  yet their contribution is invaluable.

bottom line is that we need both.  they are part of the same machine.

| |