error running cyphesis-setup.sh

[Sean Ryan]

On fedora 16 (which is still supported I think, 17 was just released).

While running the scripts/cyphesis-setup.sh script, it's using a deprecated option to createuser/createdb.

Also, hammer does something a bit funky that makes it not operational ... more to check on this.

I went searching back through previous revisions of postgres, and found that the -q option was taken off the list of options as of postgres 8.2 (which is no longer supported).

http://www.postgresql.org/docs/8.2/interactive/app-createuser.html

It may have still functioned until recently, but for f16, it is not valid. F16 uses 9.1, which as of today is the latest supported version.

sryan@charon scripts]$ rpm -qa | grep postgres
postgresql-9.1.4-1.fc16.x86_64
postgresql-libs-9.1.4-1.fc16.x86_64
postgresql-devel-9.1.4-1.fc16.x86_64
postgresql-server-9.1.4-1.fc16.x86_64
[sryan@charon scripts]$ uname -a
Linux charon.evercrack.com 3.3.6-3.fc16.x86_64 #1 SMP Wed May 16 21:43:01 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
[sryan@charon scripts]$ cat /etc/redhat-release
Fedora release 16 (Verne)

[sryan@charon scripts]$ sudo ./cyphesis-setup.sh
Welcome to cyphesis.

This script will go through the steps required to configure
your system so that you can run cyphesis. An important part of this
process is setting up access to the PostgreSQL RDBMS, so this script
must be run as root or with sudo access. It is strongly recommended that
you run cyphesis using a normal user account, and this script will help to
set up access for this account to the database.

This script will remove any existing server rules and maps, but will
preserve any user accounts in the server.

Creating PostgreSQL account for user sryan...
/usr/bin/createuser: invalid option -- 'q'
Try "createuser --help" for more information.
ERROR: ./cyphesis-setup.sh: Unable to create database account sryan.

[Al Riddoch (alriddoch)]

Wow, the Postgres team seem to have pointlessly broken the interface multiple times in its existence, providing me with no way to use a safe set of flags supported by multiple versions.

[Al Riddoch (alriddoch)]

I've pushed a fix. It works for me. Can you confirm before I mark this as committed?

[Sean Ryan (sryan)]

The fix works fine, but the script still can not execute without error. I'll let you decide whether to close based on the below =)

This script doesn't work out of hammer, it is the way that cyloadrules command is formed.

sudo ./cyphesis-setup.sh
...

Loading game rules into database...
sudo: /home/sryan/code/hammer/work/build/worldforge/servers/cyphesis/scripts/./../tools/cyloadrules: command not found

This is the line:
if sudo -u ${USERNAME} ${SCRIPTDIR}/../tools/cyloadrules ; then

But ... hammer builds it in the x86_64 directory
[sryan@charon cyphesis]$ find . -name cyloadrules
./x86_64/tools/cyloadrules

The file does not exist in the configured location.

This has something to do either with the SCRIPTDIR and how it's detected ... or the way hammer creates an arch directory (x86_64) and does a ../configure

As an option you may need to remove the cyloadrules ... and maybe print out a notice on how to execute it ( ie $PREFIX/cyloadrules ) or something. I think this is just a disconnect between hammer and the cyphesis expectations.

[Al Riddoch (alriddoch)]

This makes me wonder how it ever did work, or perhaps the person who wrote the hammer script never got around to debugging it.

Does hammer run this script every time it does a build?

[Sean Ryan (sryan)]

The hammer script doesn't run it at all, and it does not interfere with the build/install process.

What it does prevent, is a cyphesis environment that is functional, and my guess is it never worked via the hammer build environments at all.

This is one of those things realistically that you do only once. My guess is that most of the developers that have run a cyphesis instance, already had it loaded/setup. After that (meaning that a cyphesis db was created, and the few other admin type items that are less than clear ), everything is handled in the normal with in the PREFIX directory (just normal cyphesis stuff).

Nobody would need to run it, they would just start cyphesis and it would work.

Only someone that is 100% fresh would have run across this.

Also made worse by the hammer script ... is that your compile notice at the end pointing to running the script, is hidden away in a build log ... it's there, but it is essentially suppressed from the person running the hammer command.

In fact I only knew to look for it, as I compiled cyphesis prior to hammer and knew it was there =)

So someone executing the ./hammer.sh build cyphesis

E.g.

[sryan@charon cyphesis]$ pwd
/home/sryan/code/hammer/work/logs/servers/cyphesis
[sryan@charon cyphesis]$ grep -B 5 -A 5 cyphesis-setup.sh install.log
chmod 1777 /home/sryan/code/hammer/work/local/var/tmp

Cyphesis is not yet ready to run.
Unless you have configured the server to run without a database, Cyphesis
requires access to a PostgreSQL database to store rules and account data.
Please run 'sudo ../scripts/cyphesis-setup.sh' to create the
PostgreSQL account and database required, or run it as root.

For detailed instructions please see the README file.

make[3]: Leaving directory `/home/sryan/code/hammer/work/build/worldforge/servers/cyphesis/x86_64'
[sryan@charon cyphesis]$

As it's not run post-install by hammer, I ran it manually from inside the script dir (and the root build dir as well). Also based on your chat comments, the script is NOT run in the main build dir (this is done by running ../configure from a created directory, which is SOP for hammer).

[Al Riddoch (alriddoch)]

Ok, I think I follow you more clearly now, but to sort out a few points:

Firstly, you can run cyphesis without completing the setup script. It will run without any persistence, and it will display errors on startup, but it will simulate the world just fine.

Secondly, I think you should be able to run the setup script in an out-of-tree build (which hammer does), by running it from the root of the directoy where the objects files are written. I know the text output by the build implies you need to be in the scripts directoy, but this is false. If I have time I'll verify this for myself, and harden it up a bit.

[Sean Ryan (sryan)]

This is correct. Cyphesis does run fine, barring the lack of persistence as you've suggested, of course throwing some errors.

I think your second assumption is not correct though.

For example, in my case

/home/sryan/code/hammer --- This is where i checked out hammer

/home/sryan/code/hammer/work/build/worldforge/servers/cyphesis -- This is the checkout directory

/home/sryan/code/hammer/work/build/worldforge/servers/cyphesis/x86_64 --- This is the actual build directory, where the .o files are created.

[sryan@charon cyphesis]$ pwd
/home/sryan/code/hammer/work/build/worldforge/servers/cyphesis
[sryan@charon cyphesis]$ find . -name "*.o" | head -3
./x86_64/client/client.o
./x86_64/client/CharacterClient.o
./x86_64/client/Py_CreatorClient.o --- We can see that this is the root of where the objects are.

[sryan@charon cyphesis]$ find . -name cyphesis-setup.sh
./scripts/cyphesis-setup.sh
[sryan@charon cyphesis]$ pwd
/home/sryan/code/hammer/work/build/worldforge/servers/cyphesis --- And the script is in the root dir

Option 1 : running the script from the root object dir == same error
sudo: /home/sryan/code/hammer/work/build/worldforge/servers/cyphesis/x86_64/../scripts/../tools/cyloadrules: command not found
ERROR: ../scripts/cyphesis-setup.sh: Unable to load rules into database.
[sryan@charon x86_64]$ pwd
/home/sryan/code/hammer/work/build/worldforge/servers/cyphesis/x86_64
[sryan@charon x86_64]$ sudo ../scripts/cyphesis-setup.sh

Option 2: running from the source root dir
Same error

Option 3: running in the install directory
Same error

The issue is I think in the calling.

SCRIPTDIR=${PWD}/`dirname $0`
${SCRIPTDIR}/../tools/cyloadrules

[sryan@charon work]$ find . -name cyloadrules
./build/worldforge/servers/cyphesis/x86_64/tools/cyloadrules
./local/bin/cyloadrules
[sryan@charon work]$

When in reality we need something more like:

$BUILDDIR/tools/cyloadrules
or
$PREFIX/bin/cyloadrules

There is some trickiness to it though ... due to the LD_LIBRARY_PATH requires that you have it set to find the non-system wide installs of the wf libs (like wfmath ... which is the case, and IMO point of doing it with hammer in a contained directory).

Might have to require that the LD_LIBRARY_PATH be set by the user or something.

Anyway, with this change it works (it's horribly ugly though ... we should find a nicer way, this is just to illustrate the point):

sryan@charon scripts]$ git diff cyphesis-setup.sh
diff --git a/scripts/cyphesis-setup.sh b/scripts/cyphesis-setup.sh
index 366a6fe..77e72e7 100755
--- a/scripts/cyphesis-setup.sh
+++ b/scripts/cyphesis-setup.sh
@@ -144,7 +144,10 @@ echo
 # cyloadrules automatically picks up the right files for the ruleset
 # set in the main config.
 echo Loading game rules into database...
-if sudo -u ${USERNAME} ${SCRIPTDIR}/../tools/cyloadrules 2> /dev/null; then
+BUILDDIR="x86_64"
+export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/home/sryan/code/hammer/work/local/lib
+#echo "Test: ${SCRIPTDIR}/../${BUILDDIR}/tools/cyloadrules";
+if sudo -u ${USERNAME} LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/home/sryan/code/hamme
     echo Loaded.
 else
     echo ERROR: $0: Unable to load rules into database.
[sryan@charon scripts...

[Al Riddoch (alriddoch)]

The fact that hammer nests the object directory inside the source directory is confusing things. /home/sryan/code/hammer/work/build/worldforge/servers/cyphesis/x86_64 is the root of the objects directory tree, and this is where it was assumed you would be having just typed "make install" when you read the message.

However it doesn't currently work, as the script assumes that it is also located in the same tree, which is never true for an out-of-tree build. Your fix just hard codes the hammer case, as you probably know. I'll see if I can come up with a better fix soon. In the meantime, running cyloadrules by hand should fix it for you.

[Erik Ogenvik (erik-ogenvik)]

Not applicable anymore.