View Issue Details

IDProjectCategoryView StatusLast Update
0003926unrealinstallingpublic2015-07-09 19:00
Reporterwarg Assigned Tosyzop  
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionno change required 
Product Version3.2.9-RC1 
Fixed in Version3.4-alpha4 
Summary0003926: unreal script and binary conflict
Descriptionwhen user answers <somepath> for dpath and <somepath>/unreal for spath in the Config script, the result is a unreal script that calls itself because the script has replaced the binary.

it is not unrealistic to think the user would do this.

possible fixes i can think of:
1) renamed unreal to unrealrc (user is less likely to name his binary this)
2) ask for binary name only in Config, and install it to <dpath>/bin/<binaryname>
3) disallow answering with <dpath>/<scriptname>

i think #1 is the easiest way to fix this

[warg@beorn unreal]$ ./unreal start
Starting UnrealIRCd
Usage: unreal start|stop|rehash|restart|mkpasswd|version|gencloak
Possible error encountered (IRCd seemingly not started)
=====================================================
Check above for possible errors, and this output of
ircd.log. If you cannot solve the problem, read
Unreal.nfo on where to get support
=====================================================
tail: cannot open `/home/warg/test/unreal/ircd.log' for reading: No such file or directory
Steps To Reproducerun ./Config

when it asks:
What directory are all the server configuration files in?

answer /<yourhomepath>/ircd

when it asks:
What is the path to the ircd binary including the name of the binary?

answer /<yourhomepath>/ircd/unreal
TagsNo tags attached.
Attached Files
warg.option1.diff (11,549 bytes)
warg.option4.diff (1,295 bytes)
3rd party modules

Relationships

related to 0003927 resolvedsyzop patch to make --prefix and --bindir work, also adds --ircdname 

Activities

syzop

2010-07-14 17:01

administrator   ~0016162

definitely not 1, you don't want to break such things in a 3.2.x release.

I guess with 0003927 this can also be done.

Not urgent, not needed for 3.2.9, though if someone wants to create an interim fix which does option 2, sure...

katsklaw

2011-03-29 05:14

reporter   ~0016632

Last edited: 2011-03-29 05:54

IMVHO, changing the Config script is more intrusive than changing the name of the rc script. Changing the path to the binary is also more intrusive as it changes the directory structure.

As a side note if you want to use a separate bindir like $HOME/$INSTALLDIR/bin/binary then you should follow suit with the rest of the files and place logs and config files in a libdir too.

I seriously thing #1 is best in this case as said "interim fix" and change binary names and paths in 3.2.10 or later.

I've uploaded a patch for option 1 and it also fixes a slight mistruth.

katsklaw@laptop:~/Downloads/Unreal3.2$ ./unrealrc start
ERROR: Could not find the IRCd binary (/home/katsklaw/Downloads/Unreal3.2/src/ircd)
This usually means you did not answer the question correctly
during './Config', or you forgot to run 'make' and/or 'make install'.

The original says "This usually means you did not answer the question correctly
during './Config', or you forgot to run 'make install'." Which isn't entirely true, you can get the same result by running ./unreal start without running 'make' as well.

katsklaw

2011-03-29 05:52

reporter   ~0016633

warg.option4.diff

Ask user for binary name, if 'unreal' default to $DPATH/ircd and warn user.

Move along, nothing else to see!

syzop

2015-07-09 18:59

administrator   ~0018439

No longer an issue with new directory style

Issue History

Date Modified Username Field Change
2010-07-14 04:01 warg New Issue
2010-07-14 17:01 syzop Relationship added related to 0003927
2010-07-14 17:01 syzop Note Added: 0016162
2011-03-29 05:13 katsklaw File Added: warg.option1.diff
2011-03-29 05:14 katsklaw Note Added: 0016632
2011-03-29 05:14 katsklaw Status new => has patch
2011-03-29 05:29 katsklaw Note Edited: 0016632
2011-03-29 05:51 katsklaw File Added: warg.option4.diff
2011-03-29 05:52 katsklaw Note Added: 0016633
2011-03-29 05:54 katsklaw Note Edited: 0016632
2015-07-09 18:59 syzop Note Added: 0018439
2015-07-09 18:59 syzop Status has patch => resolved
2015-07-09 18:59 syzop Fixed in Version => 3.4-alpha4
2015-07-09 18:59 syzop Resolution open => no change required
2015-07-09 18:59 syzop Assigned To => syzop