View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0003926 | unreal | installing | public | 2010-07-14 04:01 | 2015-07-09 19:00 |
Reporter | warg | Assigned To | syzop | ||
Priority | normal | Severity | minor | Reproducibility | always |
Status | resolved | Resolution | no change required | ||
Product Version | 3.2.9-RC1 | ||||
Fixed in Version | 3.4-alpha4 | ||||
Summary | 0003926: unreal script and binary conflict | ||||
Description | when 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 Reproduce | run ./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 | ||||
Tags | No tags attached. | ||||
Attached Files | |||||
3rd party modules | |||||
|
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... |
|
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. |
|
warg.option4.diff Ask user for binary name, if 'unreal' default to $DPATH/ircd and warn user. Move along, nothing else to see! |
|
No longer an issue with new directory style |
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 |