View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002103 | unreal | ircd | public | 2004-10-01 14:20 | 2015-07-09 20:04 |
| Reporter | w00t | Assigned To | syzop | ||
| Priority | normal | Severity | minor | Reproducibility | unable to reproduce |
| Status | closed | Resolution | fixed | ||
| OS | Mixed(nix) | ||||
| Product Version | 3.2.1 | ||||
| Fixed in Version | 3.4-beta1 | ||||
| Summary | 0002103: Remote MOTD issues... | ||||
| Description | Ok, we have a three server network. All three with MOTDs. /motd brings up the local MOTD fine, however, when requesting a remote MOTD (ie /motd boo.netronet.com from zap.netronet.com) gives a "[23:41:07] MOTD file is missing" error. This was working until a recent bout of netsplits. /rehash has been tried to death. | ||||
| Steps To Reproduce | If you want to take a look, connect over on netronet. 3 servers: boo.netronet.com collective.netronet.com zap.netronet.com Thanks guys. | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | None | ||||
| has duplicate | 0003149 | closed | Remote motd broken? |
|
|
Note that remote motds use the ircd.motd file (so not the one from the tld { } blocks). |
|
|
Would it be possilbe to make remote motds use the right tld {} stuffs? Or is that some local thing that gets set etc? |
|
|
Possible? Yes Would it be better? I don't know I can imagine servers not wanting to show their MOTD (eg from a password protected hub) to remote/normal users, so if tld { } stuff would be done some extra option should be added. |
|
|
Well first off, you can make tld blocks apply to remote users by doing #define TLINE_Remote. Anyway though, since this has been reported before, I'm assuming it is indeed a bug. Unfortunately, I can't yet find anyway to reproduce it. Some more info would be helpful. Does boo have any tld {} blocks? If so, can you paste them? Does ircd.motd exist on boo? And any other info you can think of would be helpful as well. |
|
|
Hm? I think this is just a typical issue of a missing ircd.motd file, and a tld *@* block using a file with another name (hence, locally no problem). Ah well, we'll see indeed :p. |
|
|
I can't seem to reproduce this either short of trying renaming ircd.motd on the remote server. I think what's needed is a bit more info :) . Namely: From the IRCd: /stats tld From the shell: ls ircd.*, and ls *.*motd |
|
|
No, all three servers have an "ircd.motd" - as far as I know. I'll make sure of this soon. As for tld blocks, well, I don't think so either - I'll make sure, but unless someone's monkeyd around witht the configs since last I connected, it worked fine. By the way, doesnt say, /motd boo.* send the motd request for boo to fulfil...? Note also (I thought I mentioned it) that the problem happens 3 ways: zap.netronet.com, boo.netronet.com, collective.netronet.com are all affected. I'm also doubtful of it being a config issue since nobody has modified any config files in the past month, at least... edited on: 2004-10-03 12:00 |
|
|
Ok, I stand corrected. zap and boo both have tld blocks, and I presume non-standard motd files. The respective server admins will get back to me on this, hopefully in a day or so. Collective however, has the standard ircd.motd setup, and it's motd still can't be viewed remotely. |
|
|
an update on this bug. seems that even now (20050421, Unreal 3.2.3), remote MOTD checks don't work with tld{} blocks. even if I set options::remote. I switched to doing this recently so that I could avoid having symlinks from the ircd.motd file (and friends) to where I actually put my MOTD files, which I keep synched through the use of rsync/ssh. I only today was notified that remote MOTD checking wasn't working. |
|
|
Bump. Is this still a valid bug? |
|
|
insofar as this occurs: 09:23:42 -!- [hanashi.surrealchat.net] MOTD File is missing and the MOTDs do work when you're on the local server, but not remote. |
|
|
Fixed in 3.4-alpha5. The default is now to threat remote MOTD/RULES the same as local. Silly define is gone now. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2004-10-01 14:20 | w00t | New Issue | |
| 2004-10-01 14:20 | w00t | 3rd party modules | => None |
| 2004-10-01 15:55 | syzop | Note Added: 0007839 | |
| 2004-10-02 05:45 | aquanight | Note Added: 0007848 | |
| 2004-10-02 14:21 | syzop | Note Added: 0007851 | |
| 2004-10-02 15:52 |
|
Note Added: 0007853 | |
| 2004-10-02 16:37 | syzop | Note Added: 0007854 | |
| 2004-10-03 00:18 | aquanight | Note Added: 0007856 | |
| 2004-10-03 11:52 | w00t | Note Added: 0007862 | |
| 2004-10-03 11:59 | w00t | Note Added: 0007863 | |
| 2004-10-03 12:00 | w00t | Note Edited: 0007862 | |
| 2005-04-22 00:06 | tabrisnet | Note Added: 0009794 | |
| 2007-04-15 08:08 |
|
Note Added: 0013383 | |
| 2007-04-15 11:24 | tabrisnet | Note Added: 0013387 | |
| 2007-04-15 13:51 |
|
Status | new => acknowledged |
| 2007-04-16 12:46 |
|
Relationship added | has duplicate 0003149 |
| 2007-07-18 07:27 |
|
Relationship added | child of 0003454 |
| 2007-12-30 11:33 | syzop | Relationship deleted | child of 0003454 |
| 2015-07-09 20:04 | syzop | Note Added: 0018467 | |
| 2015-07-09 20:04 | syzop | Status | acknowledged => closed |
| 2015-07-09 20:04 | syzop | Assigned To | => syzop |
| 2015-07-09 20:04 | syzop | Resolution | open => fixed |
| 2015-07-09 20:04 | syzop | Fixed in Version | => 3.4-beta1 |
