Hi. I've been looking into setting up and running a crossfire server. My only problem is that the ebuild installs all of the files as root and I assume that the server must then run as root to be able to write to the directories. I'm too paranoid for that. Could the ebuild be modified to add a user (cfadmin?) and have everything owned by it? There probably ought to be an init.d type script for starting the server as that user.
no, it'd run under $GAMES_USER_DED feel free to post a patch to do so
I have a first pass at the chown fix but I want to do a few test runs before I post it. I'm not to sure about writing the init.d script and installing it. I don't know any of the gentoo conventions for this. I saw pvpgn makes an init.d script and installs it. Would this be a good model? Is there a better model package for this?
An init script is perfectly fine and probably the most widely-accepted way of doing this. If there are possibly options that an admin would want to pass to his server, then I would also recommend that you setup an /etc/conf.d file that the script reads for extra options, so users don't have to edit the init scripts directly.
Created attachment 85634 [details] First test ebuild This add the chmod of the state directory for the crossfire server
I've added my first pass at the ebuild. I haven't tried the init.d script yet. I need to look into the 'right way' to do the init script. Also, I'm just starting to experiment with crossfire. I'm sure having a conf file would be a good idea, but I don't know what should go in there yet. I guess I could start with a single variable that gets put on the server's command line at startup. Would I put the sample/initial conf file under games-server/crossfire-server/files?
Created attachment 85727 [details] second pass at an ebuild This one creates an init.d script and conf.d file. It depends on two otherfiles.
Created attachment 85728 [details] template init.d script This is the template init.d script used by the ebuild. It goes in the files directory.
Created attachment 85729 [details] conf.d file This is used by the ebuild as a conf.d file
Well, this is my attempt. Should the init.d and conf.d files be removed when the package is unmerged? If so, then there is atleast one bug. Let me know what I've got wrong or what could be better. This patched ebuild does the following: - it now chowns the the crossfile directory under ${GAMES_STATEDIR}/crossfire to ${GAMES_USER_DED}:${GAMES_GROUP} - it creates an init.d script that will start the server as ${GAMES_USER_DED}:${GAMES_GROUP} - it creates a conf.d file that allows the user to define a variable that will append option to the crossfire command line.
what you've posted is a good start ... but ssd should only be used if the server itself doesnt support changing user/group id, backgrounding, pid generation, etc...
I know it can background itself. I don't know how to get a PID out of it when it does. I also didn't see anything in the docs I've seen so far that suggest it can change user on it's own. Maybe there's a way. The server does support a log file, but only if you let it background itself. That would be optimal.
Based on the doc's I've read, I think ssd is probably the way to go. I haven't found a way to get it to save it's PID or switch user. If I find a way, I'll send an update. Should I add an option to nice the server?
I've found a sample init.d file on the crossfire wiki. It looks like the debian version. It uses ssd, but doesn't use the PID file option, allowing the server to background itself and then terminating it based on the '-exec' option. I can change my version to let the server background itself if that's the policy, but for some reason I prefer actually killing the server via PID rather than nuking any old process running the same executable.
Sorry. Forgot to include the link: http://crossfire.real-time.com/code/server/dc/d13/init_8d-source.html
Sorry to be a pest, but is there something more I ought to do?
Ping. What happens next? I have been running with my modified ebuild and I have notcied and problems with the init.d script at startup or shutdown. I just requested a version bump of the server and I didn't want this fix to get lost in the process.
The server code has a version bump that went through before this was completed. Should I update my ebuild for version 1.9.1 or just drop it?
Well, updating the ebuild is just fine.
I just thought of something. Since I've added an rc script, is there a standard (gentoo) way of stoping it before an upgrade and restarting it afterwards as needed? Since map files could be changed in the process I would guess you wouldn't want the server running during the upgrade. If there is no stardard handling if stopping and starting servers during an upgrade, would it be enough to just check if it is up at the beginning of src_install() and stopping/restarting it as needed?
You shouldn't ever stop and restart services automatically. If the packages *require* the service be stopped, you can search for it in pkg_setup and abort if it is running. Pretty much anything else isn't allowed. Also, it *must* be in the pkg_* sections, not src_* or it will break anyone installing a binary package made from the ebuild.
Created attachment 97473 [details] CF 1.9.1 ebuild
I've posted my current ebuild without a check for a running server. I haven't had a chance to test it yet and it might be a little bit until I can. I will also see if I can find an ebuild to use as an example for checking if the server is running and failing if it is. I feel that is important since it seems that changing the map while the server is running could likely corrupt both the running game and the newly installed map.
I upgraded from 1.9.0 to 1.9.1 using the new ebuild and it worked. I found one more issue that needs to be addressed. The change in the world map breaks player specific apartments made with the small world map. There is a script installed with the server that can upgrade a player's apartment files. I figure it would be enough to put a note in the ebuild during the install to tell the user to run /pub/games/share/games/crossfire/maps/Info/update_apart.pl as the server ID on each player directory. I figure I don't want the ebuild to do it since it renames files and changes data.
Created attachment 127912 [details] CF 1.10.0 ebuild I'm adding an update to the ebuild that with build and install 1.10.0. NOTE: I am still testing this but I thought I'd let other try to. I've gotten through the compile. I have not tried installing yet. I'll do that when I can shutdown my server tonight. Also, how do I mark files so they don't overwrite existing files during an upgrade (like high scores, ban files, motd, etc) or so they can be manually merged with something like etc-update (settings, etc)? Also, if you'd rather keep the server running as root, you can probably take the current 1.9.1 ebuild and just rename it. That's all I had to do with mine. You can do that to take care of the server for 179705. I'm going to try updating the client ebuild for myself tonight as well.
Created attachment 127922 [details] CF 1.10.0 ebuild (fix 1) Well, the 1.10.0 ebuild works as well as the 1.9.1 one, but there is a bug with how I shutdown the server the prevents the server from shutting down cleanly. I'm uploading the fix for 1.10.0. Is there any point in posting a fixed 1.9.1 ebuild?
Created attachment 127923 [details] init.d script (fix 1, no really) (oops, wrong file)
There was another version bump for the server. That means my latest ebuild will need to be made an -r1 or some such. If there is any interest in this let me know. Otherwise just mark it wontfix. I'm tired of maintaining a forked ebuild. As long as the base package never gets an init.d script, I can more easily maintain my own init.d script that does the chown's and copies in my own copy of server setting files.
Created attachment 151484 [details] Stand alone init.d file This is an init.d script designed to work around the gentoo crossfire-server ebuilds that install the crossfire server with permissions that require it to run as root. I haven't tested it much, but I want to close this bug and forget it. It's not going to be fixed. THIS SCRIPT MUST BE MODIFIED so that the variables at the top reflect the user ID & group you what the server run as, the directory where the game state data is (probably under /var) that will be chown'ed to the user and group above and the bin directory were the server executable is. My directories will almost certainly NOT match yours. Look into it. Once things are setup, you can use it to start and stop the server. I believe it will work with rc-update and such. Prior to starting the server it will do a recursive chown on the games state directory. It will then start the server under the provided user id and group. I do no error checking. Use at your own risk. Hide your pets and mind your breakables.
One quick update in case anyone uses this. The init.d script I provided fails to stop the server. I tell start-stop-daemon to send a HUP signal. That doesn't seem to work on the latest version of the server. Just remove the '--signal HUP' from the stop case and it will work as expected.
