View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000585 | unreal | ircd | public | 2002-12-28 08:18 | 2016-12-29 10:55 |
| Reporter | Wraith | Assigned To | syzop | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | *nix | OS | Redhat | OS Version | 8? |
| Product Version | 3.2-beta13 | ||||
| Fixed in Version | 4.0.10 | ||||
| Summary | 0000585: [config] include files aren't directly included | ||||
| Description | when starting the ircd: Starting UnrealIRCd _ _ _ ___________ _____ _ | | | | | |_ _| ___ \/ __ \ | | | | | |_ __ _ __ ___ __ _| | | | | |_/ /| / \/ __| | | | | | '_ \| '__/ _ \/ _` | | | | | / | | / _` | | |_| | | | | | | __/ (_| | |_| |_| |\ \ | \__/\ (_| | \___/|_| |_|_| \___|\__,_|_|\___/\_| \_| \____/\__,_| v3.2-beta13 * Loading IRCd configuration .. * unrealircd.conf:29: illegal link::class, unknown class 'servers' using default of class 'default' * Configuration loaded without any problems .. * Dynamic configuration initialized .. booting IRCd. --------------------------------------------------------------------- I've also tried changing the link class to operators, same error. | ||||
| Steps To Reproduce | Will happen when I have class { ... }; blocks in another included file. unrealircd.conf includes the .network, which has the class { ... }; block. When moving the class block to unrealircd.conf, starts up fine, no error. | ||||
| Additional Information | --> See syzop's bug note 0000585:0017273 for proposed solution (or just read all bug notes) | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
| has duplicate | 0002831 | closed | Unknown class 'clients' in oper block (CVS .467) | |
| has duplicate | 0000907 | closed | syzop | problem with .conf files |
| has duplicate | 0000936 | closed | syzop | Class definitions invisible to link definitions when included |
| has duplicate | 0004146 | closed | syzop | order of remote include processing not guaranteed |
|
|
didn't seem to put the bug recreation notes... comes up with the error when the class block is not in the unrealircd.conf - error is present when the class block is in the .network, not present when in the unrealircd.conf |
|
|
That's right, I'm having the same problem. include "classes.conf"; allow { ip *@*; hostname *@*; class clients; maxperip 3; }; I've made sure that the class definitions are before my allow{} directive. |
|
|
What about this problem, coders? It seems that the configuration parser doesn't care where include:: directives are located, and they are loaded after the main configuration file. This causes the error descripted above. I could solve the problem myself putting allow::, class::, link::, etc. directives to one configuration file or each directive to separate files in the right order. But they aren't the best solution, are they? |
|
|
Changed title. Not a nice bug indeed... maybe someone else can fix this (/me doesnt expect a fix soon ;P). |
|
|
[quote duplicate bug from creative1 (0000907)] Hi! this is the problem, when you define the class for connections (the old Y lines) you have to do it on unrealircd.conf you can't do it in any external files my problem came when i wanted to do a general.conf file for all the network with all the common stuff, which included the configuration for the Y lines, i put the class server and class client there then i did a include general.conf from the unrealircd.conf and it will never find the connection classes no matter what i did I had to move the connection classes to unrealircd.conf and then it works. Just test it out... simple to check. [/quote] |
|
|
[quote duplicate bug from aragon (0000936)] If classes are defined in a separate file and then included from unrealircd.conf all definitions are not usable from any link blocks lower down (or higher up) in unrealircd.conf. This bug has been present since conf3 from beta13 IIRC. Errors on startup: * Loading IRCd configuration .. * unrealircd.conf:117: illegal link::class, unknown class 'hub_services' using default of class 'default' * unrealircd.conf:128: illegal allow::class, unknown class 'clients' using default of class 'default' [/quote] |
|
|
Well, one option is this :) (probably won't happen but once can dream eh?). We run two seperate passes through unrealircd.conf: The first pass scans for includes and reads them in textually, similar to how #include from C(++) works. The second pass scans the resulting configuration as normal. Essentially do it like how C(++) does it. If necessary, make an internally used directive to modify the filename/linenumber (like #line) so that error reporting works right. |
|
|
aquanight forgot to say this still exists in 3.2.1 Another suggestion for conf reading: Unreal can read the conf's and put everything from the main conf and includes in 1 file in the tmp dir. Then load that file. (I dont know if this is what aqua was saying, but its in simple terms) |
|
|
Bugz: that essentially was what I was thinking. That's actually essentially how C(++) preprocessors do their work (except, I guess, when you do gcc -pipe, or for something like CL where it's all in one bundle). Though I was thinking more like storing an in-memory copy so that we don't need to keep track of yet ANOTHER temporary file :/ . |
|
|
But in-memory takes more memory! |
|
|
Only temporarily, if he's suggesting how I think he is. |
|
|
Only during startup and rehashes. |
|
|
Under aquanight's system, please parse includes until you run out. I have a master remote include file, which remote includes the actual include files and serves to keep them organized, but allows me to restructure without going everywhere, if I need to. Don't break me! |
|
|
Basically the idea is to fetch all includes, as aquanight mentioned. This is already done AFAIK: we only scan for include's in each file, and every time we see one we queue the download, only after all remote includes are fetched (including remote includes that fetch other remote includes), only after that the real parsing starts... The change proposed is then to 'merge' all these includes in one (virtual) "file". I say "file", but this has to be done in memory, so file names and line numbers are kept intact. It's of no use if you would get an error like: mergedconfig.6523865238.tmp.conf:2643: Missing quote ...which makes tracing errors impossible. Resolving this bug may require quite some effort, but if someone wants to give it a try, then feel free to do so! ;) For Unreal3.4, not 3.2, naturally. |
|
|
commit cbcbdc656a8f7bd1f58a4fd7ea0cf04dfa180859 Author: Bram Matthys <[email protected]> Date: Thu Dec 29 10:38:10 2016 +0100 The 'class' block is now always read before 'allow'. No specific order required anymore. ** I know, this doesn't fix the "include files aren't directly included" but in practice this issue has always been about class blocks not being read first and that issue is solved now :) |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2003-04-20 19:52 | syzop | Note Added: 0002433 | |
| 2003-04-30 18:54 | syzop | Note Added: 0002579 | |
| 2004-10-19 22:23 | aquanight | Note Added: 0008047 | |
| 2004-10-19 22:59 | Stealth | Note Added: 0008048 | |
| 2004-10-20 12:59 | aquanight | Note Added: 0008050 | |
| 2004-10-20 13:30 | Stealth | Note Added: 0008051 | |
| 2004-10-24 07:56 | w00t | Note Added: 0008100 | |
| 2004-10-30 21:38 | aquanight | Note Added: 0008188 | |
| 2004-12-08 12:40 | syzop | Relationship added | has duplicate 0002228 |
| 2004-12-08 12:41 | syzop | Relationship deleted | has duplicate 0002228 |
| 2006-02-23 09:37 | syzop | Relationship added | has duplicate 0002831 |
| 2006-02-23 09:40 | syzop | Relationship added | has duplicate 0000907 |
| 2006-02-23 09:40 | syzop | Relationship added | has duplicate 0000936 |
| 2006-10-17 14:30 | JasonTik | Note Added: 0012499 | |
| 2012-12-15 20:29 | syzop | Relationship added | related to 0004146 |
| 2012-12-17 10:44 | syzop | Relationship replaced | has duplicate 0004146 |
| 2012-12-17 10:46 | syzop | Note Added: 0017273 | |
| 2012-12-17 10:49 | syzop | Additional Information Updated | |
| 2016-12-29 10:55 | syzop | Assigned To | => syzop |
| 2016-12-29 10:55 | syzop | Status | confirmed => resolved |
| 2016-12-29 10:55 | syzop | Resolution | open => fixed |
| 2016-12-29 10:55 | syzop | Fixed in Version | => 4.0.10 |
| 2016-12-29 10:55 | syzop | Note Added: 0019577 |
