Show HN: Easy-to-configure Web Server in Go

by oakaz • 13 years ago

106 56 13 years ago

Uchikoma• 13 years ago

I always wonder with this kind of posts, is it minimalistic or is it an alternative?

RyanZAG• 13 years ago

It's technically an alternative, but since it performs worse and has less features you would probably never actually use it as an alternative.

It should probably be described as 'an easily embeddable and extendable(?) option for hosting your golang web app'.

oakaz6• 13 years ago

just updated the title now

jacques_chester• 13 years ago

The point is that it's written in language-du-jour and therefore fascinating and novel.

In fairness though, json will probably wind up being a common configuration format anyhow. And the idea of programmatically configurable system software is nice. I liked the Mongrel2 approach of having it in SQLite.

harrytuttle5• 13 years ago

json is fine until your config system needs accurate numeric values.

alexchamberlain• 13 years ago

Nice to see an alternative on the cards. Of course, we need some independent security reviews before this can be used seriously.

laumars7• 13 years ago

A word of warning guys, I've had a look through the code and unless I've missed the obvious, there's nothing in there to change user ID; which means this would either need to be run as root, or would need to listen on a port > 1024.

In the case of the former, that's a huge step backwards in terms of security.

In the case of the latter, that would mean you'd need another reverse proxy hooked up - which would negate the need for this web server to begin with.

This can easily be fixed within Go though:

    import (
    	"log"
	"syscall"
    )
    
    const (
    	user_id  int = 1000
    	group_id int = 1000
    )
    
    func secureDaemon() {
    	// set group id first as you need to be root to change group
    	err := syscall.Setgid(group_id)
    	if err != nil {
    		log.Fatalln(err)
    	}
    	
    	err = syscall.Setuid(user_id)
    	if err != nil {
    		log.Fatalln(err)
    	}	
    }

You can also add chroot to your code if you want to be ultra paranoid:

    import (
	"os"
    )
    
    const (
    	chroot_dir string = "/opt/go-webserver"
    )
    
    func chrootDaemon() {
    	err := os.Chdir(chroot_dir)
    	if err != nil {
    		log.Fatalln(err)
    	}

    	err = syscall.Chroot(chroot_dir)
    	if err != nil {
    		log.Fatalln(err)
    	}
    }

This will need to be done before you change your user ID (as you need root permissions to chroot) and you may need to compile the Go without CGO because some of the standard Go libraries will have SO dependencies (I found this to be the case with domain name lookups).

(the above code is adapted from my own Go web framework that I'm in the processes of building)

1331• 13 years ago

A program run as a non-privileged user can access privileged ports using authbind:

http://en.wikipedia.org/wiki/Authbind

laumars7• 13 years ago

Indeed, but it would make more sense (in my opinion) to have the web server natively 'de-elevate' it's permissions than to expect the sysadmin to be competent enough to set up authbind manually. Particularly when setuid/setgid is so easy in Go and that every other webserver out there natively drops down to a designated webuser after the daemons been launched and ports binded.

peterbotond• 13 years ago

authbind seems to defeat the purpose of privileged and non-privileged users to bind.

pjmlp• 13 years ago

Seems to be GNU/Linux only.

oakaz6• 13 years ago

thanks! would you mind sending a pull request to https://github.com/azer/boxcars/blob/master/boxcars/boxcars.... ?

laumars7• 13 years ago

I'm not on Github, sorry. But that code should be pretty easy to port to your app :)

SEJeff• 13 years ago

Why not send them a patch?

laumars7• 13 years ago

I'm not on github, which is why I made my OP so verbose; all the working code is there, s/he just needs to integrate it into their own code :-)

oakaz6• 13 years ago

just implemented -secure option for this purpose; https://github.com/azer/boxcars/blob/master/secure.go

usage example; http://github.com/azer/boxcars#security

thanks for the helpful comment!

sarnowski3• 13 years ago

Please see my comment to your parent. Additional hint: you should also care about dropping/controlling your user's groups, see https://github.com/sarnowski/mitigation/blob/master/mitigati...

sarnowski3• 13 years ago

WARNING: I implemented a tiny library for that in go a while ago. Go under Linux is not safe! Linux is not posix compliant and only sets the IDs for the current thread. Go almost always spawned more threads before initializing your code which are then still owned by root and are in the threadpool for your goroutines:

https://github.com/sarnowski/mitigation/blob/master/mitigati...

Comments mentions safe OS and golang bugticket.

laumars7• 13 years ago

I'm guessing it might depend on the point in your Go code whrn you setuid as the tests that I did on my own project, setuid changed the user id as expacted then the processes were spawned.

However you have given me reason to test my own code again and more thoroughly :-)

chrissnell• 13 years ago

It's easy enough to run this as a non-root user and use your local software firewall port to forward port 80 inbound to whatever high port this server is listening on.

laumars7• 13 years ago

Indeed, but that doesn't change the fact that it makes more sense having that functionality in the web server itself given its a standard and expected function in all web servers.

pandeiro• 13 years ago

Code organization question: is this a common convention in Go, to nest the main package in a subdirectory and put all of the 'modules' in different files but with the same package name?

(I'm more used to the Clojure namespace/filesystem symmetry, so this is somewhat new to me. I like the more shallow project tree but it's not immediately apparent where things are defined.)

redbad• 13 years ago

In a package, main or otherwise, files are purely for programmer convenience. They define import scope but are otherwise transparent to the toolchain.

sarnowski3• 13 years ago

You have to have your main() in package "main" and all your files in one directory have to be in the same package. So when you want a main() and your logic in a "real" package, your have to seperate them.

justinsb5• 13 years ago

I remain not-entirely-convinced (1) by Go, but things like this are turning the tide. If it is indeed slower than nginx, it is not dramatically so. Considering the amount of time that went in to writing each, the Go version clearly "wins" from the point of view of anyone thinking of writing new code.

(1) I find error handling just too tedious to get right (Edit: "I find error handling _in Go_ just too tedious...")

harrytuttle5• 13 years ago

From experience of running big production web apps, you need to get error handling right regardless of how tedious it might be.

A recent issue where one of our developers ate an exception cost us 12 days of developer time. Another historical issue where the error handling and return codes weren't understood and handled correctly threw 500mb of stack dumps a minute and took our logging system out.

Spent the time to get it right :)

justinsb5• 13 years ago

Totally agree, and if Go used exceptions I would probably think it perfect.

I added an edit to my comment to avoid the implication you picked up on!

joebo• 13 years ago

Looking at the benchmark (https://gist.github.com/azer/5955772), which measure suggests that its slower than nginx? I was looking at the transaction rate and the longest transaction. For reverse proxying, it seems to be as fast as nginx. For static file serving, it appears to be slightly slower. Between the two use cases, it seems like it's a negligible difference.

justinsb5• 13 years ago

I would like to know how the benchmarks are generated, but my point is that it wasn't slower-enough to ignore it, and that's amazing considering how much micro-optimization has gone into nginx and how much easier the Go version is to write.

The Go version may in fact be faster, but I don't think that's necessarily fair either: if the Go version adds features to be more comparable to nginx it would definitely slow down.

rdtsc2• 13 years ago

With benchmarks like this it worth asking 3 questions:

* Are they relevant. Does this represent the expected production workload. You could find this is 10x better than nginx at some feature but that feature is just not interesting to you then benchmarks are not that interesting

* Does the speed difference matter? Does it matter if the page loads 1ms faster when it was only 20ms before.

* Does it scale. This kind of relates to first question but it looks at abnormal amounts of traffic (Slashdot effects). Either from an attack or just becoming popular too quickly. If simply adds a server with more CPUs would that let Go server scale better than nginx? It might even though nginx could probably process sequential requests faster.

tszming• 13 years ago

json format is too limited for a web server configuration if you want to be the nginx alternative. Think about how you would represent conditional statements, how to include and reuse external configurations and how to have comments in json.

stevekemp2• 13 years ago

So it's a reverse HTTP proxy, which can also serve files locally? That's an interesting thing, no doubt, but it doesn't feel like a web-server.

I wrote a flexible reverse proxy[0] using node.js, a year or so ago, and haven't missed the ability to serve static files directly - so I'm wondering what the use-case for that is? I guess proxying to rails, or similar?

0- http://steve.org.uk/Software/node-reverse-proxy/

justinsb5• 13 years ago

Did you benchmark your node.js version? I would love to know how node stacks up here.

I agree that static serving is not as interesting, but it is useful to be able to serve up a fail-whale page!

stevekemp2• 13 years ago

Honestly I never have. Because in practise it is fast enough that it just didn't come up.

I'm sure that if I were to pimp the project properly then that would be a good thing to do, but half the fun of my proxy is to allow "interesting" rewrites, dynamically.

To benchmark I'd be too tempted try to game the results by doing a straight pass-through comparison to mod_proxy, nginx, etc. That would lose half of the appeal of the project in the first place.

JoeAcchino• 13 years ago

I'm very interested in this because this is the kind of web server I was planning to write for my work, but from a quick glance I didn't find HTTPS support.

Is HTTPS supported or planned?

oakaz6• 13 years ago

have you tried it?

simonw• 13 years ago

The custom 404 page example in the readme looked incomplete - how do you ensure those pages are served with the correct HTTP status code?

Show HN: Easy-to-configure Web Server in Go

Related Stories