Re: about packaging pokerth-server
* Evgeni Golov <firstname.lastname@example.org> [2008-01-20 22:53:21 CET]:
> Now there is some docs in the upstream SVN, which looks good enough
> for basic understanding. So I'm thinking about building a
> pokerth-server binary package for it.
> However, I do not know what would be the best way to do so:
> 1. create an init-script and run the server as nobody (like pioneers do
> for the meta-server)
> 2. create an init-script and a user pokerth which will run the server
> (like most daemons do)
> 3. just provide the needed info so the local admin can run the server
> on its own (like pioneers do with the real server, not the meta one)
> Of course #3 is not the user-friendly one, BUT:
> pokerth-server can host multiple games at the same time (usually the
> main server offered by the pokerth-developers is enough), so unlike to
> other games, it is enough when there are a couple of servers, serving
> many games each, instead of one game each (like pioneers or quake).
Then definitely have it in its own package, like wesnoth-server is
> I think I'd go for #1, which is disabled in /etc/default after install.
> What do you think?
#1 is practical, and if the server doesn't store any data that could
get exploited through some other nobody running script bug it isn't too
much of a problem to not create its own dedicated user (which though
would be reasonable nevertheless - though wesnothd also runs as nobody).
THOUGH! Do *not* do some silly START=no entry in
/etc/default/pokerth-server - this is pretty much abuse. If you don't
want to have it enabled by default you maybe want to consider calling
update-rc.d appropriately with only stop and no start symlinks. This is
the area of the rc.d files and definitely should stay there. There were
some packages that abused default files in that way but in the end
reverted that silly behavior again.
The approach is quite simple: If someone installs some server package
they propably also want to run it by default, otherwise they will change
the runlinks on themself. That is of course, if you are able to offer
reasonable defaults, otherwise you would have to fall back to debconf
questions for that.