Bug 46057 - Ebuild for ut2004 dedicated server
|
Bug#:
46057
|
Product: Gentoo Linux
|
Version: unspecified
|
Platform: All
|
|
OS/Version: Linux
|
Status: RESOLVED
|
Severity: enhancement
|
Priority: P2
|
|
Resolution: FIXED
|
Assigned To: games@gentoo.org
|
Reported By: cuban@drunkstudents.net
|
|
Component: Games
|
|
|
URL:
|
|
Summary: Ebuild for ut2004 dedicated server
|
|
Keywords:
|
|
Status Whiteboard:
|
|
Opened: 2004-03-28 19:03 0000
|
This ebuild will install the ut2004 dedicated server for x86 or amd64. It is
based on the ut2003-ded ebuild and the ut2004-demo ebuild.
Reproducible: Always
Steps to Reproduce:
1.
2.
3.
Actual Results:
*** Bug 45626 has been marked as a duplicate of this bug. ***
I'll get on this as soon as I get some free time and am at my dev box.
Sorry for the delay... we are testing all unreal-based games to ensure that
they are not exploitable with a common exploit released 2 weeks ago that allows
remote code execution. Once we've cleared ut2004-ded, we'll add it to portage.
Quite alright. Be aware that I've observed the dedicated server being extremely
bug-ridden under certain circumstances. One of my reasons for requesting this
ebuild is so that I can file a bug if ut2004ded is still noticably broken on my
machine, and work with other people to discover what the common element between
our systems are.
Things that I've noted on my own system. I'm mentioning them here for the sake
of reference, and will file the appropriate Gentoo/Epic bug reports once I've
confirmed that the below has nothing to do with a misconfiguration on my part
(the ebuild will help me confirm this):
1) './ucc-bin help' only showing a single item, 'help'. (not all that helpful
considering I had to know that already to get that far, eh?)
2) Instability when enabling the MapVote feature. Crash on first login.
3) Webserver providing inconsistent functionality. Drop-down boxes will often
contain no selectable items at all. If items are selectable, all of the maps
may not be visible.
Again, I'm only mentioning this for the sake of those doing the current ebuild
testing so that others will know that they are not alone. Once the ebuild hits
portage I can hopefully work with others to learn what combination of
hardware/software cause the dedicated server to exhibit the behavior, assuming
this isn't a problem created by something in the provided default.ini file.
Thanks, I wasn't aware of the icculus.org Bugzilla. Doing so!
Any word on the other bugs?
I would like to get this added to portage at some point, if possible.
OK. I am waiting for the new UT2004 patch to be released before I add this to
portage. Just thought I would give everyone a status update.
The patch has been out. Status?
Got a new ebuild that uses the new 3236-1 patches? At the moment, I am
preparing for a new release, so I don't have a lot of time to invest into
writing new ebuilds, as I am working to stabilize existing ones, but submission
of a working ebuild that is *known* to not be exploitable by the recent unreal
engine security flaws will definitely get things sped along, since all I would
have to do is QA the ebuild and make sure it works, then commit it.
The following submission is a modified version of the ebuild written James
Jones, also utilizing the (modified) initscript submitted by Ken Smith. This
ebuild contains the most recent official patch, which fixes all known exploits
listed on the front page of http://unrealadmin.org. It has been tested by
myself and installs cleanly on x86. Should be ready for QA testing - tell me
what you think guys.
Changes from initial submission by James Jones:
* Corrected URL for the main download. (it had changed)
* Grabs latest patch and applies it before installing.
* Installs the (modified) initscript submitted by Ken Smith.
* Increased the verbosity of the postinstall message:
Shows location of default.ini and provides a URL showing how to edit it.
Explains that registration is not necessary for a private/unfindable.
Changes to the initscript by Ken Smith:
* Adjusted formatting of variables, otherwise unchanged.
Thanks... I'll check it out as soon as I get a chance (next day or two)...
FYI, there's no need to post a Manifest or digest, since I'll have to download everything myself anyway, and it is part of the CVS check-in procedure.
Sorry, I was just following suit with the earlier poster - I'm big on posting
bugs, but this was the first time I got cornered into doing any of the real
work. ;) I'll remember that in the future.
Let me know what you think too.
Argh, I would have to say that was my last change. Okay, here's a note for QA
then:
The patch adds the unrelated ut2004-bin and ut2004-bin-linux-amd64 binaries to
the System directory. Since this is a dedicated server install, both of these
should be deleted - they aren't needed.
Created an attachment (id=34443) [details]
games-server/ut2004-ded/ut2004-ded-3236.ebuild
Check out this ebuild... it fits in a little better with what our normal
ebuilds look like. I also fixed a few things. See if this ebuild works for
you.
I also had to "un-dos" it. You had uploaded it in dos format... ;]
Whoops! The first ebuild I submitted was probably okay since it came straight
from the testing machine, but the changes were done from a Windows machine at
work. My fault. ;)
I noticed that the options supplied to the initscript are in the initscript
itself, which I believe is non-standard. Should these be moved to a conf.d
entry?
Created an attachment (id=34447) [details]
games-server/ut2004-ded/ut2004-ded-3236.ebuild
Here's one with ut2004-bin* removed. The options probably should be moved to a
conf.d entry, though.
Anyway, for some reason this ebuild is passing QA but still breaking when I try
to emerge it, so I'm not sure what is going on with it right now. I'll have to
dig into it more when I have some time. You're definitely welcome to figure
out what the problem is and fix it. It definitely isn't syntax-related,
though.
If I can't figure it out, I'm going to re-type the ebuild by hand, since the
conversion could have done something wonky.
I'm testing this right now, don't go anywhere. ;)
A few more notes before I get to the weird stuff:
Patch version is actually 3236-1, not 3236. Since there actually is a 3236 patch, the name should probably reflect this somehow.
Needs a depend for app-arch/bzip2 since the patch is in bzip2 format.
Alright, about the weirdness: I combed the file with cat -e and found nothing unusual about the file. The conversion seems to be fine at a glance. So I proceeded to retype the contents of your ebuild in file from scratch (on my test server, no conversion involved), with the exception that I used a simple echo statement in the src_install() and pkg_postinst() functions since the problem wasn't occuring in them. Same. Exact. Problem.
If there isn't a syntax problem present, you've managed to uncover one hell of an obscure bug. But I've ruled out DOS->UNIX conversion being the problem.
Blah, grammar. in file = in a new file
Also, let's confirm that we're talking about the same error here:
bzip2: Can't open input file /usr/portage/distfiles//usr/portage/distfiles/ut2004-lnxpatch3236-1.tar.bz2: No such file or directory.
That is definitely *not* the error that I was getting. I was having portage
dump a traceback.
If you change line 36 (I think, counted by hand) to read unpack ${PATCH_P}
instead, you shouldn't get the error that you were anymore. Also, could you
post your ebuild/init script typed by hand?
Oh yeah, there's no need for regular echo. Use einfo/ewarn instead.
Also, there's no reason to add bzip2, since it is in the system profile on all
supported arches. We can always assume that things in the system profile
(glibc, gcc, bzip2, etc) are always present on a working Gentoo system.
That's why one has to be careful when they say syntax or bust. :) People may be
inclined to believe you! Thanks for the note about bzip2 though, live and
learn.
Anyway, that fixes the problem I *was* having, but now I'm running into
another:
* This will take a while ... go get a pizza or something
chmod: cannot access
`/var/tmp/portage/ut2004-ded-3236/image//var/tmp/portage/ut2004-ded-3236/image///opt/ut2004-ded/System/ucc-bin':
No such file or directory
This is using your posted ebuild, which I fetched from the website with wget.
You may wish to try the same. I'll post the retyped ebuild since you requested
it, however.
Remove ${Ddir} from the fperms line and see if it works...
The following error occured (have bzip2 installed):
>>> Unpacking /usr/portage/distfiles/ut2004-lnxpatch3236-1.tar.bz2 to /var/tmp/portage/ut2004-ded-3236/work
bzip2: Can't open input file /usr/portage/distfiles//usr/portage/distfiles/ut2004-lnxpatch3236-1.tar.bz2: No such file or directory.
>>> Source unpacked.
nostrip
>>> Install ut2004-ded-3236 into /var/tmp/portage/ut2004-ded-3236/image/ category games-server
* This will take a while ... go get a pizza or something
cp: Aufruf von stat f
The following error occured (have bzip2 installed):
>>> Unpacking /usr/portage/distfiles/ut2004-lnxpatch3236-1.tar.bz2 to /var/tmp/portage/ut2004-ded-3236/work
bzip2: Can't open input file /usr/portage/distfiles//usr/portage/distfiles/ut2004-lnxpatch3236-1.tar.bz2: No such file or directory.
>>> Source unpacked.
nostrip
>>> Install ut2004-ded-3236 into /var/tmp/portage/ut2004-ded-3236/image/ category games-server
* This will take a while ... go get a pizza or something
cp: Aufruf von stat für ,,/var/tmp/portage/ut2004-ded-3236/work/UT2004-Patch/*" nicht möglich: Datei oder Verzeichnis nicht gefunden
!!! ERROR: games-server/ut2004-ded-3236 failed.
!!! Function src_install, Line 44, Exitcode 1
!!! Patching server to current...
I just added this to portage using a modified version of my above ebuild.
Enjoy
