[TUTORIAL] [Guide] - Installing Xonotic (autobuild) in Fedora/Redhat/Centos/Scientific Linux

Install Xonotic on Redhat/Centos/Scientific Enterprise Linux flavors (also works with Fedora 17)

In order to get Xonotic running we first need to prep our box. I'll have listed below a checklist of the things we need, with their corresponding links, followed by the instructions used to get Xonotic up and running.

*Guides for gnubs, written by gnubs. This is how I personally get Xonotic running on my Centos 6 desktop computer. I have tried it like this on Fedora 17 in the past. I will be making improvements on the guide as i continue to make improvements myself. You can use the applications, programs, text editors, methods you see fit in replacement of any the methods i use here.
**Disclaimer, you break anything, yata yata yata, not my fault. period. end of story.

Now, on with the fun stuff ;]

Checklist:
EPEL repository added to our system (not required with Fedora)
Xonotic.zip downloaded (or the autobuild for the latest release)

Links:
Epel - http://fedoraproject.org/wiki/EPEL/FAQ#H...ository.3F

Xonotic - Latest (Stable) release (xonotic-0.6.0.zip) = http://www.xonotic.org/download/
or Xonotic – Autobuild release (using rsync script provided by divVerent, a member of the xonotic community) - http://forums.xonotic.org/showthread.php?tid=1863


Firstly, lets add the EPEL repo, since we'll be pulling dependencies from there. ( skip adding the repo if you are on Fedora)
So, lets open up a terminal and log in as root

su
rpm -Uvh http://download.fedoraproject.org/pub/ep...noarch.rpm

yum -y install rsync nano wget unzip darkplaces SDL
cd /usr/games

--Now, We can either use the latest 'stable' verion, or we can use the autobuilds method...

--stable release
wget http://dl.xonotic.org/xonotic-0.6.0.zip
unzip xonotic-0.6.0.zip

--autobuild
wget http://rm.rm.rm-f.org/~xonotic/xonotic-a...loader.zip
unzip xonotic-autobuild-downloader.zip
rm cyg* *.exe *.bat xonotic-autobuild-downloader.zip
chmod +x update-xonotic.sh
./update-xonotic.sh

--and whichever package you choose, continue by running:
cd Xonotic
chmod a+x xonotic-linux*


Now to create a shortcut on your desktop
so first, lets start by exiting root...

exit
nano ~/Desktop/Xonotic.sh

and make sure the file has this inside

cd /usr/games/Xonotic
./xonotic-linux-sdl.sh


That's It.. We're done!!!

You can now run Xonotic on your Enterprise Linux, and all other users will be able to access the same directory if they like. (feel free to put the game wherever you like, that's just where i ended up putting it)

Enjoy!!!
Come play with us. make sure to stop by the 'Player6E Space-Time Continuum' server also.
Thanks to everyone who contributes to this awesome game!!!
Any feedback, suggestions for improvement are welcomed. I wish i had this install guide awhile back ;]



***(For those on Fedora, i simply ran 'yum install nexuiz' to see what packages i needed to install for it, and i deducted which ones would actually be required to work with Xonotic. Nexuiz and nexuiz-data i left out, and only installed the SDL and darkplaces packages)

nano and wget are not Xonotic dependencies, you could use curl to download the files instead (Xonotic needs libcurl anyway) and instruct users to use their text editor of choice Also, rsync is only a dependency for autobuild.

You also should not be pulling DarkPlaces from distro repositories, DP is distributed with Xonotic already. Xonotic also does not use vanilla DarkPlaces, it uses the div0-stable branch. If you use your distro's DarkPlaces build along with Xonotic's autobuild, you might run into incompatibilities because autobuild is bleeding-edge and therefore expects a bleeding edge div0-stable engine. But in any case, your instructions don't even make use of the darkplaces you install with yum, so you can simply drop that from the yum line.

I would also strongly suggest that you do not put things in /usr/games without the aid of a package manager. I'm saying this because, if the user tries to install a Xonotic package in the future, they will risk file conflicts or loss of the previous files. So, if anything, put it in /usr/local/games, but making a package is probably the safest way to go. But since you're doing the shortcut install in user space (which means other users don't really notice it's there), you should not install Xonotic system-wide anyway: just extract it somewhere in $HOME and symlink Xonotic/xonotic-linux-glx.sh and Xonotic/xonotic-linux-sdl.sh to the desktop or create launchers for these two scripts.

EDIT: If you're really making a system-wide install, providing .application .desktop (sorry) files for the users' choice DE in /usr/share/applications (seems like /usr/local/share/applications isn't widely recognized, that sucks) and symlinks in /usr/local/bin to the two launcher scripts are better than putting a shell script on selected users' desktops. Or make a package with the right files in /usr/bin, /usr/games and /usr/share/applications.

What do you need EPEL for?

Your guide is also lacking instructions on how to update autobuild, which is essential if you're going to use them.

---

I also removed a few characters in your post title by changing the comma-space to a single slash, otherwise people can't reply to this thread because the added "RE: " to the title makes it too long to post.

If ppl are writing guides for normal players on how to get/use the development version of the game, cause the stable is too old, I think it's high time for a new stable release :-P.

Well kudos, Mr Bougo, for successfully Trolololing my first post here on the forums. It only seems fitting that you get the honors, considering all the help you have provided me and others on IRC in the past. Your post was just as annoying as it was informative. ;]

So what you are saying is SDL is the only thing i need from EPEL?... (since, darkplaces is contained already, and those were the only packages i pull from there... the deps pull from centos base).

Let's assume i have 10 people who access and play xonotic on my pc... extracting in $Home for each is not practical at all (especially in my case where my hard disk is full to the brim already).


Okay, so to make xonotic seamless to the system... my /usr/local/bin is bone dry... no files at all. First off, to avoid making my own package (as i am gnub and all), let me understand this: if i create an .application file with the rest of them, and link my xonotic.sh scripts in /usr/bin, where would i put the Xonotic folder once its extracted?

I'll gladly update my post with the recommended disclaimers, etc. in the future. For now, i want to sort out a practical way of making Xonotic systemwide, and seamless (links in the applications area, for gnome and kde, xfce, etc.).

Thanks again for all the help mate!!


And Yes, i agree... an updated stable-release is probably due and in-line. On that note, who's to say they aren't already ahead of us on this? ;]

Ah, I didn't realize I had talked to you before! I'm sorry my post annoyed you, I guess you had it coming when you welcomed feedback

The fact that your /usr/local/bin is empty isn't that surprising, package managing tools often don't place anything there and it's left to the sysadmin to use as they wish without fearing too much interference. Hopefully, if you check your $PATH, you'll see that it's still included in there, so it's a good way to install system-wide executables that aren't managed by yum.

I'll correct what I said above: there seems to be a standard for .desktop files (I said .application above, sorry, that was wrong) that says they can be located in /usr/local/share/applications as well: see here and check your $XDG_DATA_DIRS environment variable if it's empty or contains /usr/local/share.

In any case, here's what I would do. Bear in mind that I am not a package maintainer and I don't have much experience in the field at all, I'm taking inspiration from Arch's Xonotic package, see also its xonotic-data dependency.

First, extract the release files into /usr/local/games/xonotic/ or /usr/local/xonotic/ and symlink the xonotic-linux-sdl.sh and xonotic-linux-glx.sh to /usr/local/bin/xonotic-sdl and /usr/local/bin/xonotic-glx (1).

Then, make a couple of desktop files: xonotic-sdl.desktop and xonotic-glx.desktop (Arch files linked for your convenience; fix the version, icon path, and make the exec part point to the new /usr/local/bin links.) Put these files in /usr/local/share/applications if that turns out to work (hopefully it does,) /usr/share/applications otherwise.

That's pretty much it! Xonotic should then be available from application menus thanks to the .desktop files and from the command line thanks to the /usr/local/bin links. Plus, making a desktop shortcut becomes a trivial task for the user if they want one.

SDL is indeed a dependency (although it is optional because there is the GLX alternative, but it's good to have anyway.) You also need libcurl, otherwise maps can't be downloaded.

Are you sure you need to set up EPEL to get SDL? If not, you don't need EPEL instructions at all, which would be nice.

Footnote:
(1) those two are actually the same file, they detect whether the name of the executable contains sdl or not and launch the right binary based on that.

I guess the following process for system-wide installation of stable releases works in major Linux distributions including Debian/GNU, Ubuntu, and maybe Fedora. For getting autobuild versions, take a look at http://forums.xonotic.org/showthread.php?tid=1863. If in doubt, follow your distros' conventions. Good luck.

1: Extract the released archive into an appropriate directory such as /opt, /usr/local, or somewhere else on your local filesystem that all of your users have read access to and your operating system does not modify without your consent.

2: Give 755 permission to Xonotic/data directory, or only the owner can run the game because that directory has 700 permission by default.

3: Create a symbolic link to the lauch script of your choice in /usr/local/games, or /usr/local/bin, or somewhere else that is listed in $PATH and your system does not modify. This step lets you start the game by a single command from your terminal emulator.

4: Try to launch the game from your terminal emulator. If it won't, read the messages left in the terminal. Probably it is complaining that some libraries are missing, so install them and try again. Repeat this until the game runs without any complaints. Some distros might require third-party software repositories. Configure SELinux or AppArmor or the like if needed. Note that libcurl is required for online gameplay while it is not needed to start the game.

5: Create a .desktop file for the game in /usr/local/share/applications. You can use those for other major applications as templates. The specification can be found at http://standards.freedesktop.org/desktop...atest.html. This step lets you start the game from your application laucher such as Activities and Kickoff.

6: If you have a special icon for Xonotic, copy it to /usr/local/share/icons/hicolor/scalable/apps, /usr/local/share/icons/hicolor/48x48/apps, and so on. The spec can be found at http://standards.freedesktop.org/icon-th...atest.html. You can find some icon files in SVG and PNG formats in Xonotic/misc/logos.

7: If you will run dedicated servers, see Xonotic/server/readme.txt for the installation instructions.

I wouldn't put the server.cfg in the data directory without editing it first. And anyway, it's better to place it in $HOME/.xonotic/data/.

Also, I don't think setting the dedicated server to 700 is reasonable, because running the server as root definitely isn't. Perhaps make it 750. But even then, I don't see what prevents a user from downloading or compiling a dedicated server binary and run that? I'm no pro though.

It's a good thing that you mention SELinux and AppArmor, but I doubt TimelesslyPrecise knows how to configure them. I certainly don't.

Also, thanks for mentioning the icon files, I was not aware of these.

You are right about server.cfg, but I am afraid that you misunderstand the server setup step. The server launch script (server_linux.sh) has to be in the the directory where the server executables are, or otherwise the script complains that it is not properly set up yet.

You are right about the permission, too. That permission change would work against casual attempts only, if ever. If we seriously want to prevent unauthorized users from launching their own servers, we need to activate SELinux with the strict policy. Anyway, I don't think this is a matter of big concern, because TimelesslyPrecise's users probably won't dare to do that.

Adding a special user or a goup for running the dedicated server is definitely a good idea. I agree 750 is more suitable than 700. I will correct my previous post.

Oh sorry, I misread your message. You were talking about the launch scripts, not the config file. You're absolutely right.